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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Mon Jul 9 07:51:13 UTC 2012


On 2012-07-07 23:21, XMPP Extensions Editor wrote:
> Version 0.3 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: Edits recommended from public discussion. (MDR)
>
> Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.2/vs/0.3
>
> URL: http://xmpp.org/extensions/xep-0301.html
>
Mark,
This looks good. I have some comments, but very few influence the protocol.
So even if there are minor adjustments to do, the spec looks mature.

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 
solutions:
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 
specification.
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 4.5.4.1 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 4.5.4.2. The actions to avoid it 
should be more on the sender side as I propose here.

21. Section 4.5.4.2 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 4.5.4.2 First paragraph, third line from end: after 
"message" insert "used"  for explanation why an internal copy is kept.

23. Section 4.5.4.2 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 6.5.3.1. Please divide in paragraphs for easier reading.

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

32. Section 6.5.3.2. 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.

Regards

Gunnar

___________________________________________________
Gunnar Hellström
Omnitor
gunnar.hellstrom at omnitor.se
+46708204288



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


More information about the Standards mailing list