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

Mark Rejhon markybox at gmail.com
Sun Jul 22 01:19:56 UTC 2012


Hello XSF members (Peter and Kevin, et cetra)

I incorporated Gunnar's edit today.  Do you prefer I submit an 0.5
immediately before you review?  The only changes I did were editorial --
word edits, phrase edits and sentence edits/moves, in approximately 15
locations, no protocol changes over 0.4.

On Sat, Jul 21, 2012 at 1:46 AM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> wrote:

>  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.
>

1. Done [1 sentence move] -- Barry recommended it be a standalone sentence,
too.
2. Done [1 sentence edit] -- Made similiar but not identical edit
3. Done [2 words added] -- I used "and reproduction"
4. Done [1 word edit] -- Verbatim edit


 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.
>

5. Edit deferred -- explanation given in earlier email message.
6. Done [1 word removed] -- I removed the word "accessibility"
7. Done [1 phrase edit] -- Verbatim edit
8. Edit deferred -- It is a standard XMPP Core terminology. Other specs
don't first explain JID (e.g. XEP-0296)


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. "
>

9. Done [1 word added] -- Already done in v0.4
10. Done [1 phrase change] -- Verbatim edit
11/12. Edit Deferred -- It is merely an introductory example. Also, if
people chunk text instead of preserving key press intervals, then
whole-word burst transmission is greatly preferred over broken-word burst
transmission.
13. Edit Deferred -- It's a great suggestion in theory, but in all
practicality, the change is too confusing. Most implementers of
blind-assistive software will figure out "display" means "reception" or
"present to the user" ....  The word "display" is pretty standard in many
XEP's, from a search I did. Even it's an XML element in some, i.e. XEP-0202
(A Final standard) uses a <display/> element.



> 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.
>

14. Explanation -- Cancel is critical to the needs of several implementers.
See Activating/Deactivating text section
http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text
....
Also, cancel is 100% appropriate for multi-login session.   I clarified the
MUC chapter to say that cancel should not deactivate outgoing transmission
since it would allow one participant to suppress real-time text between
other willing participants.  (senders may still use it, in order to discard
their unfinished real-time message when logging off, etc)
However, an edit was made to the Activation/Deactivation section to clarify
cancel behaviour during Multi-User Chat.
[2 sentences modified]



> 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.
>

15. Done [1 sentence modified] -- Now refers to A.3.2.1
16. Done [4 words added] -- Verbatim edit. It is true there are exceptions,
longer intervals also can cause less congestion on GPRS and be more usable.
17. Done [1 word changed] -- Verbatim edit.
18. Edit deferred -- Explanation given in long email.


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.
>

19. Edit deferred -- Explanation given in previous email. It helps reader
associate WHICH definition of "character" we are using. Even the RFC's say
that the word has multiple interpretations, so it's appropriate here in the
title. The title is like a glossary entry, and the contents explain we're
using code points as the method of counting characters.
20. Edit deferred -- I didn't like adding the paragraph either, but
following your suggestion will complicate implementations.  If I do your
suggestion, it will no longer be easy to do "Monitoring Message Changes
Instead Of Key Presses"
http://xmpp.org/extensions/xep-0301.html#sending_realtime_text because I
would no longer be able to treat the real-time message as easily as if it
was essentially "an array of code points". You are a strong advocate of
this method too, and I'm sure you agree with me you don't want to
complicate section 6.4.1
21. Already done -- The edit was already done in v0.4
22. Already done -- The sentence was already rewritten (albiet differently
from your suggestion).


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".
>

23. See my explanation in 20.  Suggestions of shortenings are welcome.
24. Done [1 word changed] -- I think you referred to section 4.6.2
25. Already Done -- I think it's already done in 0.4 -- I don't see any
"That there" -- I ran a grammar checker for v0.4


> 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.
>

25/26/27. No longer applicable -- I already rewrote the paragraph in
section 5 for 0.4



> 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.
>

29. Edit deferred -- same explanation as 13
30. This is editorial related, so can wait for LAST CALL if there are
multiple agreements.
31. Already done -- In 0.4, it says "(whether unsupported or turned off)"
32. This is editorial related, so can wait for LAST CALL if there are
multiple agreements.
33. Edit deferred -- Although an implementation detail and there are good
reasons to almost always save it, but not 100% always.
34. Not possible since the de
35. Done [name fixed] -- Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120721/49c4fc08/attachment.html>


More information about the Standards mailing list