[Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL

Gunnar Hellström gunnar.hellstrom at omnitor.se
Sat Jul 21 05:46:56 UTC 2012

On 2012-07-21 04:55, Mark Rejhon wrote:
> On Fri, Jul 20, 2012 at 9:33 PM, XMPP Extensions Editor 
> <editor at xmpp.org <mailto:editor at xmpp.org>> wrote:
>     Version 0.4 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: Spelling, grammar, and clarification edits, including
>     section clarifications recommended from public discussion. Interop
>     with XEP-0308 message correction. (MDR)
>     Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.3/vs/0.4
>     URL: http://xmpp.org/extensions/xep-0301.html
> ......
> I would appreciate opinions about announcing LAST CALL, for this 
> specification.
> Thank you so much, everyone!
> Mark Rejhon

That was a huge amount of edits.
Luckily, very few of them affect protocol, so my judgement is still that 
the specification is mature and can go for Last Call if the XEP 
management so decides.

However, I sent a bunch of edit hints on July 9, and see none of them 
I would like to see them applied or commented why they should not be 

Here they are in their original form, relating to version 0.3.

These are my observations and propsals:

1.  Chapter 1, last line:  Move last sentence first. And make an empty 
line after it. Now it takes the whole chapter before we get to know what 
the specification is about.

2. Chapter 1, last bullet point. Change to: " As one medium in Total 
Conversation, e.g. deployed in the European project REACH112 [5] for 
accessible communication and emergency service."
Motivation:                     ( Total conversation was the theme. It 
was about both person-to-person and emergency service)

3. Section 2.1, point 4.   add "and replication" after "transmission".  
( just transmission is not sufficient for the intended effect.)

4. Section 2.2, point 3. change "traversal protocols" to "traversal 
mechanisms",   because they are more mechanisms than protocols.

5. Section 2.4, Title. Change to "Usable for mainstream and 
accessibility purposes."

6. Section 2.4, point 1. Change word "accessibility" to "service 
description".   Because F.703 is a general standard. The total 
conversation part is of accessibility interest.

7. Chapter 3,  Real-time text. Change "in real time" to "instantly" , to 
match definition in chapter 1.

8. Chapter 3, Add "JID" and its explanation.

9. Section 4.1, second line.  Add "client" after "sender", to make it 
clear that the user dies not need to bother about transmission.

10. Section 4.1 Second paragraph. Change word "live" to "in real-time"   
to be consistent.

11. Section 4.1, Example 1, Line 9 ,  make the text part "my Ju"  , so 
that it is obvious that it is not about word by word transmission.

12. Section 4.1, Example 1, Line 15 ,  make the text part "liet" only,   
so that it is obvious that it is not about word by word transmission.

13. Section 4.2.2 event='new' third line.  change "display, and then 
process" to "reception, and then process text and"    . Because we must 
not assume that all applications display the text. "

14. Section 4.2.2 event='cancel'.  How does this behave through 
multi-user chat and multiple login situations? Is the event='cancel' 
sent through to all? I see a risk that one user sending event='cancel' 
would turn off rtt for all recipients. If this is true, I see three 
a) Delete event='cancel'. b) Add a sentence saying "event='cancel' SHALL 
not be used in a MUC or multi-login session.  c) Add a sentence saying 
"event='cancel' SHOULD be ignored in MUC and multi-login sessions.
I have a slight preference for solution a), to delete cancel from the 
If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with 
"cancel" shall be deleted.

15. Section 4.4, line 3, after "F.700" insert "usability requirement 
section A.3.2.1" so that the reader understands why this requirement 
exists and where to find it.

16. Section 4.4, line 3, after "conversation", add "in most network 
conditions".   On GPRS, having 1.5 s network latency, the usability 
requirement will not be met, and that must be accepted. ( F.700 requires 
2 seconds end-to-end for usable real-time text and 1 second for good 
real-time text. )

17. Section 4.5, last word. Replace "delivered" with "completed" .

18. Consider deleting the "Forward Delete" d action element. It cannot 
be used with the default value for p because that would point outside 
the real-time message. Therefore, a p must always be calculated and 
included. Then it is equal in complexity to use it as Backspace. Having 
both just seem to add complexity to implementations. ( It would have 
been different and of value if it worked from a current cursor 
position.)   But if you have good reasons, e.g. easily matching some 
editing operation result, you can keep it.

19. Section 4.5.2, third bullet point. I would like to see the words 
"Unicode Code Points" replace "Unicode Character Counting". Code points 
is the safe base that we count.

20. Section At the end, insert paragraph: "Characters consisting 
of multiple Unicode code points SHOULD be sent together in the same <t/> 
element. Values of /*p*/ and /*n*/ SHOULD NOT result in pointing within 
such combinations of code points."    ( this is to avoid the situations 
described with the long note to section The actions to avoid it 
should be more on the sender side as I propose here.

21. Section First paragraph, line 3. Delete the sentence 
starting "In an ideal....". There are different standard Unicode 
normalizations, so a receiver normalizing received Unicode that was 
normalized by the sender may result in change of Unicode. This does not 
matter and the sentence was just an effort to explain.

22. Section First paragraph, third line from end: after 
"message" insert "used"  for explanation why an internal copy is kept.

23. Section The Note is correct, but very long. I would like to 
see it shortened but have not wording proposal at the moment. It aims at 
avoiding situations that I suggest prevent by my proposal 20 on the 
sender side.

24. Section 4.6.1 first line, replace "does" with "do"

25. Section 4.6.3, the Note.  replace "That there" with "There".

26. Chapter 5. 2nd paragraph after box, delete "is" in "is SHOULD NOT"

27. Chapter 5. last paragraph. add "support" after "discovery".

28. Chapter 5. last paragraph. I hesitate a lot about this simple way of 
detecting support. We need a proper way to detect RTT capability before 
we start to use it. There may be systems that have to select between 
different protocols for RTT, and they should not need to start sending 
in one protocol to try to discover if RTT is supported.
Still, I realize the convenience of this simple method, and would let a 
discussion decide if it shall be kept.
If it is kept, the paranthesis characters on the second line should be 
deleted so that the rapid response on this initiation is made part of 
the protocol.

29. Section 6.2.1 Last paragraph, first line. Replace "display" with 
"handle".   There may be other than displaying terminals handling the rtt.

30. Section Please divide in paragraphs for easier reading.

31. Section Middle. Add "support" after "Participant clients 
without real-time text"

32. Section Please divide in paragraphs for easier reading.

33. Section 6.5.4. The default action for a non-completed message should 
be to regard it completed after some time, not to clear it. So, replace 
"clear (and/or save)" with "save".

34. Chapter 14. Is there a way to express the default value for p in a 
schema?  If so, insert it.

35. Chapter 15. "Hellstrom" should be spelled with double l.

As you see, only comments 14, 18, 28 and 33 really affect the protocol.

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

More information about the Standards mailing list