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

Barry Dingle btdingle at gmail.com
Tue Jul 10 00:20:48 UTC 2012


Really good job. My suggestions are mainly minor edits. Some (hopefully)
improve the meaning.

My Numbers relate to the Section numbers. They have reasons with them where
= = = =

*1.* (Edit) I think the last sentence should be a separate paragraph. (It
is not really part of the paragraph it is in now. And it will highlight the
sentence more which is needed.)

*4.* We need to add some context before we dive into the detail.

Add the following (before 4.1 heading):
"This specification is an extension of XMPP (*XMPP Core* [8]). It uses XMPP
terminology."  (To this point in the specification it implies the use of
XMPP but it does not explicitly state it.)

*4.1* (Edit) Last sentence (immediately before Section 4.2)

Make the last sentence a new paragraph on its own. (It does not relate to
sentence before it and it is a requirement that should be highlighted.)

*4.2.1* (Edit) Add text to clarify meaning of last sentence of 2nd paragraph

". . . to keep <rtt/> compact, *but should allow for *plenty of
incrementing room without overflow."

*4.3* Clarify what happens in the 2nd sentence.

"The *content of the <body/> element in the *delivered message is displayed
instead of the *contents of the accumulated <rtt/> elements of
the*real-time text message."

*4.5* Clarify 2nd sentence of 2nd paragraph by removing the words 'before
sending' at the end of the sentence. The words removed are misleading when
present as the real-time text has been sent.

"The inclusion of real-time text functionality to existing client software,
needs to preserve the sender's existing expectation of being able to edit
their messages."

** (Edit) Last sentence.

“It is noted *that* conversion of line breaks into a single LINE FEED . . .
. “

*5.* 2nd last paragraph. Remove the word 'is' as it should not be there.

“Enabling/disabling of discovery *is* SHOULD NOT be the default method of
activating/deactivating real-time text.”
***6.2.1*    In the first of the 4 bullet points – remove 'else' or remove
'as well' as this is repetitive.

  Question – Do we need Either of those terms? Can we remove both of them?

In the 2nd bullet point, remove 'also'.

 *6.3*   2nd paragraph 1st sentence – remove the 2 commas as they are not

 *6.4.1*   (Add) 2nd sentence – state what needs to happen

   “. . . simply retransmitted every Transmission Interval *with
event='reset'* whenever there are any text changes.”

   3rd sentence – add 'example' - “The *example* below . . . ”

 **   (Edit) 3rd bullet point – clarify and simplify end of sentence

  “If there are no changes to the real-time message, then no <rtt/> element
needs to be transmitted.”

 **   (Edit) Spelling 'receiving' and remove the unnecessary 'that'

  “in the order they are received.”

 *6.5.1*   Last paragraph – remove plurals – change

  from “. . clients that sends” to “. . clients that send”

  from “. . when messages reaches” to “. . when messages reach”

 *6.5.4*   Last paragraph - remove plurals 'resumes' and 'continues'

  “Senders that *resume* composing a message (i.e. *continue* a ”

 *6.5.5*   1st paragraph, 3rd sentence – remove plural

  “Real-time messages *need* to be updated . . ”

 *7.1*   (Edit) Correct text after first message example.  Change "HLLO" to

  "The above code sends the misspelled "*HLL*", then <e/><e/> backspaces 2
times, then sends "HELLO"."

The 3 examples have the words “The above code . . .”. It is not *code*.
  All 3 cases should be changed to start with “The *example* above . . . “

 ***7.2.2*   1st sentence - Change “The below example . . “ to “The example
below . . “. Better English.

*7.3.1*   2nd last sentence - We should not be referring to code here.
Maybe try rewording the sentence like:

  “This is because the text *"Hello Bob, this is Alice!"* is output then *<d
n='4' p='5'/>* deletes 4 characters from position 5.”
   (This improves consistency with explanatory text in other sections. )

 *7.3.2*   Same comment as 7.3.1 applies here with different details.

 *7.3.3*   Same comment as 7.3.1 applies here with different details.

 *8*    First paragraph – simplify wording to:

  “There are other real-time text standards. Interoperability between those
standards and this specification may be required. For each environment
where interoperability is supported, an interoperability specification
needs to be documented that covers addressing, session control, media
negotiation and media transcoding.”

*8.2*   2nd paragraph – several small edits – see edited whole paragraph
below. Change 'addressing' to 'address' ; remove unnecessary commas, add
'for' ; add 'processing' to indicate what is being referred to.

  “Interoperability implies *address* translation, media negotiation and
translation, and media transcoding. For media transcoding between this
specification and T.140/RFC 4103, the real-time text transcoding is
straight forward except *for* the editing feature of this specification.
Backwards positioning and insertion or deletion far back in the message can
cause a large number of erase operations in T.140 that take
*processing*time and bandwidth to convey.”

 *Appendix D*   - XMPP is defined by RFC 6120 and RFC 6121 (and maybe RFC

= = =

Barry Dingle
Fixed - +61(0)3-9725-3937    Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Electrical and Electronic Eng.,
> Apple + Linux + Open Source software

On Mon, Jul 9, 2012 at 5:51 PM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> wrote:

>  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 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.
> Regards
> Gunnar
> ___________________________________________________
> Gunnar Hellström
> Omnitorgunnar.hellstrom at omnitor.se+46708204288
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120710/ba97fd3d/attachment.html>

More information about the Standards mailing list