<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 2012-07-21 04:55, Mark Rejhon wrote:<br>
    </div>
    <blockquote
cite="mid:CAA79oDkWCygMgG-m4ApB=iCeKtLhH3hasEozYe5d82pGJUFTog@mail.gmail.com"
      type="cite">On Fri, Jul 20, 2012 at 9:33 PM, XMPP Extensions
      Editor <span dir="ltr"><<a moz-do-not-send="true"
          href="mailto:editor@xmpp.org" target="_blank">editor@xmpp.org</a>></span>
      wrote:<br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          Version 0.4 of XEP-0301 (In-Band Real Time Text) has been
          released.<br>
          Abstract: This is a specification for real-time text
          transmitted in-band over an XMPP session.<br>
          Changelog: Spelling, grammar, and clarification edits,
          including section clarifications recommended from public
          discussion. Interop with XEP-0308 message correction. (MDR)<br>
          Diff: <a moz-do-not-send="true"
            href="http://xmpp.org/extensions/diff/api/xep/0301/diff/0.3/vs/0.4"
            target="_blank">http://xmpp.org/extensions/diff/api/xep/0301/diff/0.3/vs/0.4</a><br>
          URL: <a moz-do-not-send="true"
            href="http://xmpp.org/extensions/xep-0301.html"
            target="_blank">http://xmpp.org/extensions/xep-0301.html</a></blockquote>
        ......<br>
      </div>
      I would appreciate opinions about announcing LAST CALL, for this
      specification.
      <div>
        Thank you so much, everyone!</div>
      <div><br>
      </div>
      <div>Mark Rejhon</div>
    </blockquote>
    <br>
    Mark,<br>
    That was a huge amount of edits.<br>
    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.<br>
    <br>
    However, I sent a bunch of edit hints on July 9, and see none of
    them applied. <br>
    I would like to see them applied or commented why they should not be
    applied.<br>
    <br>
    Here they are in their original form, relating to version 0.3.<br>
    <br>
    These are my observations and propsals:<br>
    <br>
    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.<br>
    <br>
    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."    <br>
    Motivation:                     ( Total conversation was the theme.
    It was about both person-to-person and emergency service)<br>
    <br>
    3. Section 2.1, point 4.   add "and replication" after
    "transmission".  ( just transmission is not sufficient for the
    intended effect.)<br>
    <br>
    4. Section 2.2, point 3. change "traversal protocols" to "traversal
    mechanisms",   because they are more mechanisms than protocols.<br>
    <br>
    5. Section 2.4, Title. Change to "Usable for mainstream and
    accessibility purposes."<br>
    <br>
    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.<br>
    <br>
    7. Chapter 3,  Real-time text. Change "in real time" to "instantly"
    , to match definition in chapter 1.<br>
    <br>
    8. Chapter 3, Add "JID" and its explanation.<br>
    <br>
    9. Section 4.1, second line.  Add "client" after "sender", to make
    it clear that the user dies not need to bother about transmission.<br>
    <br>
    10. Section 4.1 Second paragraph. Change word "live" to "in
    real-time"   to be consistent.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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. "<br>
    <br>
    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: <br>
    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.   <br>
    I have a slight preference for solution a), to delete cancel from
    the specification.<br>
    If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with
    "cancel" shall be deleted.<br>
    <br>
    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.<br>
    <br>
    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. )<br>
    <br>
    17. Section 4.5, last word. Replace "delivered" with "completed" .<br>
    <br>
    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.<br>
    <br>
    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.  <br>
    <br>
    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 <i><b>p</b></i> and <i><b>n</b></i>
    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.<br>
    <br>
    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. <br>
    <br>
    22. Section 4.5.4.2 First paragraph, third line from end: after
    "message" insert "used"  for explanation why an internal copy is
    kept.<br>
    <br>
    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. <br>
    <br>
    24. Section 4.6.1 first line, replace "does" with "do"<br>
    <br>
    25. Section 4.6.3, the Note.  replace "That there" with "There". <br>
    <br>
    26. Chapter 5. 2nd paragraph after box, delete "is" in "is SHOULD
    NOT"<br>
    <br>
    27. Chapter 5. last paragraph. add "support" after "discovery".<br>
    <br>
    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. <br>
    Still, I realize the convenience of this simple method, and would
    let a discussion decide if it shall be kept.<br>
    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.<br>
    <br>
    29. Section 6.2.1 Last paragraph, first line. Replace "display" with
    "handle".   There may be other than displaying terminals handling
    the rtt.<br>
    <br>
    30. Section 6.5.3.1. Please divide in paragraphs for easier reading.<br>
    <br>
    31. Section 6.5.3.1. Middle. Add "support" after "Participant
    clients without real-time text"<br>
    <br>
    32. Section 6.5.3.2. Please divide in paragraphs for easier reading.<br>
    <br>
    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". <br>
    <br>
    34. Chapter 14. Is there a way to express the default value for p in
    a schema?  If so, insert it.<br>
    <br>
    35. Chapter 15. "Hellstrom" should be spelled with double l.<br>
    <br>
    <br>
    As you see, only comments 14, 18, 28 and 33 really affect the
    protocol.<br>
    <br>
    Thanks,<br>
    Gunnar<br>
  </body>
</html>