On 2012-07-21 04:55, Mark Rejhon wrote:
On Fri, Jul 20, 2012 at 9:33 PM, XMPP Extensions Editor
<edi...@xmpp.org <mailto:edi...@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
Mark,
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
applied.
I would like to see them applied or commented why they should not be
applied.
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
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.
Thanks,
Gunnar
