<meta content="text/html; charset=ISO-8859-1"
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2012-07-23 16:32, Kevin Smith wrote:<br>
<pre wrap="">Right, thoughts about 301 (consider them early Last Call feedback, I
guess. I think it would be worth addressing them, or at least
producing an errata list of your expected edits, before asking too
many other people to review this (e.g. LC) as it took me a
considerable time and it'd be a shame to waste people's effort
commenting on things due to be changed):
== Introduction ==
This seems mostly fine. I wonder about the reference to
realjabber.org. Partly because it's a reference to a potentially less
stable URL, and partly because I think the name is inflammatory - did
the XSF or Cisco grant the trademark use?
Do we need two references to how much deaf people like this within ten lines?
== Requirements ==
2.3.4 doesn't seem quite right - what we want is for it to be possible
to produce gateways for interoperability - not that XEP 301
implementations themselves interop with other networks?</pre>
But we prefer to have it suitable for interoperating through
gateways. Some protocol considerations may have been spent to insure
E.g. the determining support part.<br>
Will it help to move the words "via gateways" up a bit to become
Be interoperable <font color="#cc0000">via gateways </font>with
other real-time text protocols, including RFC 4103 and ITU-T T.140.<br>
2.4 Doesn't seem to be about Accessibility.</pre>
I agree, I have asked to get Usability into the heading. E.g.
"Usability and Accessability"<br>
However, I am not sure that we all agree on what interpretation of
accessibility we have.<br>
For me it is accessibility for people with disabilities, meaning in
this case that it enables people with disabilities to use another
modality of communication with equivalent functionality as
mainstream technology ( read: voice phones ).<br>
2.4.4 Doesn't make much sense to me.</pre>
Be a usability enhancement for mobile phone text messaging and
mainstream instant messaging by reducing waiting times.<br>
== Glossary ==
"real-time text"'s definition seems wrong - it isn't necessarily
transmitted instantly in 301. It would seem more natural to define
this in terms of real-time, defined on the immediately preceding line.</pre>
This is interesting. We have really tried to create an easily
understood definition. <br>
Rather than using technical terms as real-time, we selected
"instantly" that we hoped would be understandable also for
non-technical people, so that the same definition can be used
anywhere. "Instantly" was expected to carry some flexibility
covering a wide range of time situations.<br>
A parking guard requesting "You must move this car away from this
spot instantly." would accept that it takes you 30 seconds before it
A video camera salesman saying: " the video is transmitted instantly
to the file server", would mean that it is done within a second or
We do not want it to be interpreted as 30 seconds, but rather it
should be interpreted as within a second.<br>
Is this acceptable?<br>
== Protocol ==
"to allow the recipient to see the sender type the message" - I'd
suggest "to allow the recipient to receive the latest state of the
message as it is being typed" - RTT doesn't allow us to see the sender
Example 1: I suggest that this could be better demonstrated by not
cutting at the word boundaries "He", "llo, m", "y Juliet!" maybe, or
something like that. Experience and/or cynicism say that implementers
are quite likely to look at the examples, ignore the text, and
misunderstand what's going on if the examples provide convenient
semantics not required by the protocol.</pre>
I thought Mark already did that, but I see now that it is not done.<br>
"The bounds of seq is 31-bits, the range of positive values of a
signed integer" - I'd be inclined to make this something like "The seq
attribute has an upper bound of 2147483647 (2^31 - 1). If this upper
bound is reached the following RTT element will reset the seq
attribute to 0, i.e. at the upper bound the values would be (in
successive stanzas) 2147483646, 2147483647, 0, 1)" or words to that
It's not clear to me why setting seq to a random initial value should
help with MUC or multi-resource cases - in these cases you know the
full JID of the entities involved and a random start point seems to
make it harder to understand what's going on, rather than easier.</pre>
On the other hand, if security by encryption is applied, it is
always good habit to have as few fixed values in protocol data as
"The event attribute MAY be omitted from the <rtt/> element during
regular real-time text transmission" - what is the the alternative
you're allowing clients, and what is "regular real-time text
4.2.2 - "Recipient clients MUST initialize a new real-time message for
display" - how things are rendered in clients are generally not in
scope for XEPs, maybe just remove 'for display'?</pre>
4.2.2 - "Senders MAY send subsequent <rtt/> elements that do not
contain an event attribute" if clients want to always send event
attributes, what would they send?</pre>
6.4.3 Has the maybe a bit odd way to use event='reset' in every
4.2.2 - "Recipients MUST treat 'reset' the same as 'new'." - I'm not
sure that's quite right. If recipients want to render 'new'
differently that seems to be fine. Maybe "Recipients MUST reset the
state of the current real-time message when receiving a 'reset'
(returning the real-time message to the same state as when receiving a
4.2.2 - event='init' - I'm reading the XEP linearly so maybe this will
be clear later, but at this point in reading the XEP it's not clear to
me what the inclusion of event='init' buys us.
4.2.2 - The normatives here don't seem to be congruent. event='cancel'
is OPTIONAL, yet we have a SHOULD for behaviour on receiving them. Why
not require recipient support?
4.2.3 - I don't think the intent here is clear. Particularly it's not
OPTIONAL if you're doing RTT correction. So I think we need to tighten
this up. There's a choice on discovery and it'll affect what needs to
Choice 1) If you implement 308 and you also implement 301 you MUST
support (at least receiving) RTT correction and ids are not OPTIONAL
and MUST be included on the correction RTT.
Choice 2) You can implement 308 and 301 yet not support RTT
correction - in which case supporting RTT correction is OPTIONAL, but
if you do you MUST advertise appropriate disco features and MUST
include ids etc.
4.3 - "The delivered message in the <body/> element is displayed
instead of the real-time message" - maybe "The content of the <body/>
element is considered the final text, rather than the state of the RTT
4.3 - "In the ideal case, the message from <body/> is redundant since
this delivered message is identical to the final contents of the
real-time message." - can we s/message/text/ here? Calling child
elements of <message/> stanzas messages seems potentially confusing.
4.3.1 - Is this redundant?
4.4 - The discussion of throttling here feels a bit odd. I don't like
having references to servers dropping messages as part of congestion
handling, as that's not compliant behaviour. The comments about 0.7
seconds being fine for not hitting throttles but smaller values
hitting it seems a bit hit-and-miss - servers are free to implement
whatever throttling they want, and I'm a little worried about
recommending here what we think the state of the network is likely to
be now or in the future.
4.5 - "the recipient can watch the sender" - this isn't quite right
(similar to previous comment).
4.5.1 - I'm not sure that the use of quite cryptic one-character
elements here is terribly useful.
4.5.1 - I think this has been commented on elsewhere, but using
'characters' here seems to be less clear than talking about code
points. I understand the desire to mask implementers from needing
exposure to code points, but I don't think that's going to ultimately
help uptake or interoperability.
4.5.1 - I think if there are going to be SHOULDs in supported features
we should try to explain in what circumstances it's acceptable to
ignore the SHOULDs.
4.5.2 - Talking about message length here probably needs clarification
- is it the number of characters (whatever they mean to different
people), code points, normalised code points, octets on the wire...
126.96.36.199 - This might become clearer later, but at this stage it's not
clear what 'positions' are.
188.8.131.52 - Apart from adding complexity I'm not sure what forward
delete is buying us vs. backspace.</pre>
4.5.4 - I don't think trusting that nothing in the chain is going to
transform unicode in any way is going to be sufficient for
interoperability here. I think we need to consider normalising the
text before RTT calculations are performed on it. I'm not entirely
convinced, without going through specs in some detail, that an
implementation that does choose to do normalisation somewhere on route
is non-compliant, which is what's asserted here.
184.108.40.206 - Ah, OK. So you do require normalisation here - you need to
say which type is required.
220.127.116.11 - This then forbids normalisation again.
18.104.22.168 - Question for Unicode experts. Are there any code points that
would be illegal to transmit on their own, but are legal in
combination with others? If so, they'd get rejected with stream
errors, which would probably be bad. This section seems to imply that
illegal UTF-8 encoding is expected, which is in turn illegal XMPP.
22.214.171.124 - "A single UTF-8 encoded character equals one code point" -
this isn't true, is it?</pre>
If we instead say<br>
"A single UTF-8 encoded Unicode Character equals one code point."<br>
Is true, and then we need to define Unicode Character as the
Character concept used in the Unicode standard.<br>
And maybe a note saying that "Note that some visible characters are
composed of more than one Unicode Character."<br>
This is as far as I got for now.<br>