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
