-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've started to perform a complete review of XEP-0301. Here is the
first half of my feedback, in order of reading. Many of these comments
are nits but others are more significant.
1. Please expand acronyms on first use (e.g., TTY, SIP, UI).
2. "It can also allow immediate conversation in situations where
speech cannot be used (e.g. quiet environments, privacy, deaf and hard
of hearing)."
This is a bit unclear. For instance, what is a "privacy situation"?
This could be phrased more carefully, such as:
"It can also allow immediate conversation in situations where speech
cannot be used (e.g., in quiet environments, when using text preserves
privacy better than speech would, and when one or more interlocutors
is deaf or hard of hearing)."
Another relevant scenario might be speech transcription. I think
that's worth adding here:
"It can also allow immediate conversation in situations where speech
cannot be used (e.g., in quiet environments, when using text preserves
privacy better than speech would, during speech transcription, and
when one or more interlocutors is deaf or hard of hearing)."
3. "For a visual animation of real-time text, see Real-Time Text
Taskforce [5]."
If the author provides an image file, the XSF can host this page on
xmpp.org. I would prefer to do so.
4. "Reliable real-time text delivery." Please at least make this a
sentence: "Provide reliable real-time text delivery." More
substantively, what do we mean by "reliable delivery" here? What level
of reliability is expected (e.g., so-called "guaranteed delivery",
at-least-once delivery, at-most-once delivery, etc.)? Are
acknowledgements required per-stanza (e.g., XEP-0184) or is
stream-level reliability (e.g., XEP-0198) enough?
5. What do you mean by "network traversal mechanisms"? We hope that
all stanzas will traverse the network. :) Perhaps you mean NAT traversal.
6. "Compatible with multi-user chat (MUC) and simultaneous logins." =>
"Be compatible with multi-user chat (MUC) and simultaneous logins."
7. "Protocol design ensures integrity of real-time text" => "Ensure
integrity of real-time text". More substantively, what is meant by
"integrity" here? See for instance RFC 4949:
$ data integrity
1. (I) The property that data has not been changed, destroyed, or
lost in an unauthorized or accidental manner. (See: data integrity
service. Compare: correctness integrity, source integrity.)
2. (O) "The property that information has not been modified or
destroyed in an unauthorized manner." [I7498-2]
Usage: Deals with (a) constancy of and confidence in data values,
and not with either (b) information that the values represent
(see: correctness integrity) or (c) the trustworthiness of the
source of the values (see: source integrity).
Depending on the definition of "integrity" being assumed here,
end-to-end encryption might be needed. More clarity, please. :)
8. Please separate "allow extensions for new features" from "ensure
integrity of real-time text" -- these are two quite different
requirements.
9. "Allow XMPP to follow the ITU-T Rec. F.703" => "Help enable XMPP
applications conform to ITU-T Rec. F.703" (as far as I understand it,
the RTT spec will not by itself enable XMPP applications to conform to
F.703, and I don't think XMPP itself could be said to so conform).
10. "The bounds of seq is" => "The bounds of seq are"
11. "Recipient clients MUST ignore <rtt/> containing unsupported event
values." => "Recipient clients MUST ignore <rtt/> elements containing
unsupported event values."
12. event='cancel'
"Clients MAY use this value to signal the other end to stop
transmitting real-time text."
What if the sending client disables RTT? Does it send a message with a
body element and then no subsequent messages containing <rtt/>
elements? Does it need to signal that it has disabled RTT? Could
'cancel' be used for that purpose?
13. "This id attribute refers to the <message/> stanza containing the
<body/> that is being edited (See 'Business Rules' in XEP-0308). When
used, id MUST be included in all <rtt/> elements transmitted during
message correction of the previous message. The whole message MUST be
retransmitted via <rtt event='reset'/> (Message Reset) when beginning
to edit the previous message, or when switching between messages (e.g.
editing the new partially-composed message versus editing of the
previously delivered message)."
Examples would help here. In particular, when you say "the whole
message MUST be retransmitted" I assume that means something like this:
<message to='[email protected]' from='[email protected]/orchard'
type='chat' id='a04'>
<body>Hello, my Juliet!</body>
</message>
<message to='[email protected]' from='[email protected]/orchard'
type='chat' id='a05'>
<rtt xmlns='urn:xmpp:rtt:0' action='reset' id='a04' seq='54987'>
<t>Hello, my Juliet!</t>
<t> p='9'> dearest</t>
</rtt>
</message>
<message to='[email protected]' from='[email protected]/orchard'
type='chat' id='a06'>
<body>Hello, my dearest Juliet!</body>
</message>
14. I think it would be good to make it 100% clear that the <body/>
element is not qualified by the RTT namespace:
OLD
The real-time message is considered complete upon receipt of a <body/>
element in a <message/> stanza.
NEW
The real-time message is considered complete upon receipt of a
standard <body/> element (i.e., qualified by the 'jabber:client'
namespace) in a <message/> stanza.
15. I like the previous suggestion to change "0.7 seconds" and "0.3
seconds" to "700 milliseconds" and "300 milliseconds" respectively.
16. Why is support for the <e/> element only RECOMMENDED for senders?
Given that most users will hit the backspace key (or equivalent)
fairly frequently, I'd argue for REQUIRED.
17. Do the 'n' and 'p' attributes really need to be of type
nonNegativeInteger? That seems a bit big for a typical message. For
example, unsignedLong has a maxInclusive of 18446744073709551615 and
unsignedShort has a maxInclusive of 4294967295. That seems quite
enough for one RTT message!
18. I find the bullet points in Section 4.6 slightly confusing, e.g.,
"resuming after connecting". What is exactly is being resumed and who
exactly is connecting? If I come online and you're in the midst of
sending me messages, my client doesn't have anything to "resume",
although it does need to adjust to the fact that there's a real-time
text message in progress (somehow).
19. I found "switching systems, switching windows" confusing until I
realized that you were talking about switching between devices or
switching between windows/tabs in a given client. Please expand a bit.
(Also under 4.6.3: "switched systems" => "the user switched from one
device to another".)
20. "For implementation simplicity, recipient clients MAY track
incoming <rtt/> elements per bare JID." Please use the &LOCALBARE;
entity here so that readers who are new to XMPP understand what we
mean by "bare JID". (Same for &LOCALFULL; later in this paragraph.)
21. "Conflicting <rtt/> elements, from separate Simultaneous Logins,
is handled via the remainder of this section." => "The handling of
conflicting <rtt/> elements from separate Simultaneous Logins is
described in the remainder of this section."
22. "Alternatively, recipient clients MAY keep track of separate
real-time messages per full JID and/or per <thread/>." It would be
good to specify what it means to keep track of RTT messages per
thread. Citing XEP-0201 might help, as well.
23. "When the recipient sends a presence update (e.g. from offline to
online);" ... does the same reasoning apply to other presence updates,
such as from "away" to "xa" or from "dnd" to "chat"? I'd like to make
sure that this advice is truly general.
24. "When the conversation is unlocked (e.g. section 5.1 of XMPP IM
[10]);" ... please consider citing XEP-0296 here, too.
25. "Note: There are no restrictions on using multiple Action Elements
during a message reset (e.g. typing or backspacing occurring at the
end of a retransmitted message)." This seems potentially confusing.
IMHO it would be friendlier for the recipient to process the reset as
the state of the RTT message at a point in time and for the sender to
then send additional <rtt/> elements for subsequent modifications.
(Postel's Law and all that.) However, that's unenforceable so I
suppose it's OK as-is.
26. "The Unicode characters of the real-time text needs to make it
transparently from the sender to the recipient, without unexpected
modifications after sender pre-processing." s/needs/need/ Also,
"transparent" doesn't seem like the right word here. I would say "The
Unicode characters of the real-time text need to be transmitted
unaltered from the sender to the recipient, without unexpected
modifications after sender pre-processing." And later "Transparent
transmission" => "Unaltered transmission".
27. "Any inconsistencies that occur during real-time message editing
(e.g. non-compliant servers that modify messages, incorrect Unicode
Character Counting) will recover..." That is strangely worded. We
don't talk about editing elsewhere, and the inconsistencies won't be
the ones doing the recovering (although the recipient can recover from
the inconsistencies). I suggest rewording this paragraph.
28. The section on Unicode Character Counting is blessfully clearer
than I recall. I suggest clarifying the first bullet point even further:
OLD
Multiple Unicode code points (e.g. combining marks, accents) can form
a combining character sequence.
NEW
Multiple Unicode code points (e.g. combining marks, accents) can form
a combining character sequence. In addition, some combining character
sequences (represented by multiple code points) can be transformed
into a visually equivalent composite character (represented by a
single code point), or vice-versa (e.g., under Unicode normalization).
29. "separate and concurrent to" => "separate from and concurrent to"
30. "Pre-processing before generating real-time text, include" =>
"Pre-processing before generating real-time text includes"
31. "sender clients SHOULD ensure the message is in Unicode
Normalization Form C ("NFC"), specified by section 3 of RFC 5198, and
within". Note: NFC is not defined in RFC 5198! This would be clearer:
"sender clients SHOULD ensure the message is in Unicode Normalization
Form C ("NFC"), as recommended within section 3 of RFC 5198 and
within..." Furthermore, it would be good to cite TR15 here:
http://www.unicode.org/reports/tr15/
32. "If Unicode combining character sequences (e.g. letter with
multiple accents) are used for Element <t/> – Insert Text, then
complete combining character sequences SHOULD be sent." This seems
more consistent with NFD than NFC (which performs recomposition). That
is: are you recommending that applications perform compability
decomposition so that they break a composite character into a
combining sequence? If so, then you really want NFD, not NFC. IMHO it
would be safer to use composite characters wherever possible, rather
than decomposing composite characters into combining sequences as a
recommended practice. In any case, NFC will perform recomposition
anyway, so this advice might be moot (or at least confusing).
See also:
"It is possible for Element <t/> – Insert Text to contain any subset
sequence of Unicode code points from the sender’s message. This can
result in situations where text transmitted in <t/> elements is an
incomplete combining character sequence (e.g. Unicode combining
mark(s) without a base character) which becomes a complete sequence
when inserted within the recipient's real-time message (e.g.
additional accent for an existing combining character sequence). These
are still complete individual code points, even if the sequence is
incomplete."
I'm not sure how the recipient's client will show a combining mark
without a base character, but the potential for user confusion might
be high, here.
[to be continued...]
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAu0OIACgkQNL8k5A2w/vxAogCg4xndUxo0RDqikRR1cRGoP0yc
M3kAoIUw8nlBQbHu/69sPFGY0I8U1YCT
=Ckva
-----END PGP SIGNATURE-----
