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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Sun Jul 22 22:00:53 UTC 2012


On 2012-07-22 03:19, Mark Rejhon wrote:
>
> 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.
>

Mark, thanks for taking the trouble to transpose my edit proposals to 
0.4 and creating and submitting 0.5.
Even if there are a few remaing items I am not in total agreement with 
you about, I think these could either be accepted as you have proposed 
them or be accepted as editorial changes during a last call.

See some comments on these below. ( stille referring to 0.3 section 
numbering)

>
>     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. "
>
>
> 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.
But why do you want to confuse the reader with giving the impression 
that transmission is word-wise, when it is time-sampled in reality. I 
suggest to accept my edit proposal in order to not cause wrong 
impression what it is all about.

> 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.
I was thinking of non-displaying software as gateways, 
multi-party-bridges, applications etc. They never "initialize a new 
real-time message for display". But I can accept your proposal. The 
final intention is in most cases to display.
>
>     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]

I need to see this before judging.

>
> 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.
>
>
> 18. Edit deferred -- Explanation given in long email.

Forward delete just introduces complexity. Since you do not have the 
concept of "current position" in the specification, a forward delete and 
a backspace of anything else than the last character are equally long in 
coding.
But, if you want to have these two codings of the same operation, I can 
accept 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.
>
>
> 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.
I still regard this dangerous and confusing. We are counting Unicode 
code points, and that needs to be clear in all explanations.
> 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

I think that typing of characters resulting in a multiple of code points 
will result in these code points being submitted to display at the same 
time, and therefore easily can be put into the same <t/> element.  This 
is valid for example for the combining diacritical marks 300 -36F, that 
normally are displayed together with their base character.
http://unicode.org/charts/PDF/U0300.pdf
Usually nothing is displayed on the sending side until both have been typed.
Putting both in the same t-element simplifies for both the transmitter 
and the receiver. The receiver does not need to handle an outstanding 
combinable diacritical mark waiting for its base character.
There would also be no risk that text in edits combine in an erroneous 
way with already existing code points, before next message arrives 
containing the correct second half of the character.

So, keeping combined characters together is a good goal and 
simplification and should be adviced with a "SHOULD".


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.
>
> 23. See my explanation in 20.  Suggestions of shortenings are welcome.
Original
Note thatElement <t/> -- Insert Text 
<http://xmpp.org/extensions/xep-0301.html#element_t_insert_text>is 
allowed to contain any subset sequence of Unicode characters from the 
real-time message. This may result in certain situations where the text 
transmitted in <t/> elements is allowed to be temporarily an 
incorrectly-formed Unicode string. (i.e. non spacing characters, 
orphaned diacritic, orphaned control character including 
direction-change character for bidirectional Unicode, incompletely 
formed glyphs, etc.) but becomes correct when inserted into the middle 
of the recipient's real-time message, and passes recipient 
validation/normalization with no character modifications. Note that a 
compliant XML processor does not modify or fix Unicode errors caused by 
taking only a subset of characters from correctly-formed Unicode text. 
One alternative way for implementers to visualize this, is to visualize 
the Unicode text as an array of individual code points, and treat 
thepandnvalues accordingly.

Proposal
Note thatElement <t/> -- Insert Text 
<http://xmpp.org/extensions/xep-0301.html#element_t_insert_text>is 
allowed to contain any subset sequence of Unicode characters from the 
real-time message. This may result in certain situations where the text 
transmitted in <t/> elements is allowed to be temporarily an 
incorrectly-formed Unicode string. (i.e. non spacing characters, 
orphaned diacritic, orphaned control character including 
direction-change character for bidirectional Unicode, incompletely 
formed glyphs, etc.) but becomes correct when inserted into the middle 
of the recipient's real-time message. The thepandnvalues should not be 
allowed to point inside characters consisting of multiple code points, 
and the code points of such combined characters should be sent in the 
same <t/>element.


>
>
> 25/26/27. No longer applicable -- I already rewrote the paragraph in 
> section 5 for 0.4
>
Yes, good to distinguish between service discovery, and activating support.
There is something missing in a sentence in version 0.4, chapter 5.
In order for an application to determine whether an entity supports this 
protocol, where possible it SHOULD use the dynamic, presence-based 
profile of service discovery defined in .


What was your intention after "in"?

In version 0.4,  section 6.2 looks complex and need further 
restructuring now before I can judge the final result of the protocol.


>     30. Section 6.5.3.1. Please divide in paragraphs for easier reading.
>     32. Section 6.5.3.2. Please divide in paragraphs for easier reading.
>
> 30. This is editorial related, so can wait for LAST CALL if there are 
> multiple agreements.
Yes, please do
> 32. This is editorial related, so can wait for LAST CALL if there are 
> multiple agreements.
Yes, please do
> 33. Edit deferred -- Although an implementation detail and there are 
> good reasons to almost always save it, but not 100% always.
Well, quite important to not lose messages. mention that save is the 
normal, but that there may be application situations where discard is valid.


Thanks,

Gunnar

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


More information about the Standards mailing list