[Standards] XEP-0301 0.5 comments

Gunnar Hellström gunnar.hellstrom at omnitor.se
Mon Jul 23 18:46:15 UTC 2012

On 2012-07-23 16:32, Kevin Smith wrote:
> 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?
But we prefer to have it suitable for interoperating through gateways. 
Some protocol considerations may have been spent to insure that.
E.g. the determining support part.
Will it help to move the words "via gateways" up a bit to become this:

Be interoperable via gateways with other real-time text protocols, 
including RFC 4103 and ITU-T T.140.
> 2.4 Doesn't seem to be about Accessibility.
I agree, I have asked to get Usability into the heading.  E.g. 
"Usability and Accessability"

However, I am not sure that we all agree on what interpretation of 
accessibility we have.
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 ).

> 2.4.4 Doesn't make much sense to me.
How about
Be a usability enhancement for mobile phone text messaging and 
mainstream instant messaging by reducing waiting times.
> == 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.
This is interesting. We have really tried to create an easily understood 
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.

A parking guard requesting "You must move this car away from this spot 
instantly." would accept that it takes you 30 seconds before it is done.
A video camera salesman saying: " the video is transmitted instantly to 
the file server", would mean that it is done within a second or so.
We do not want it to be interpreted as 30 seconds, but rather it should 
be interpreted as within a second.

Is this acceptable?

> == 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.
I thought Mark already did that, but I see now that it is not done.
> "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
> effect.
> 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.
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 possible.
> "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
> transmission"?
> 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'?
I agree.
> 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?
6.4.3 Has the maybe a bit odd way to use event='reset' in every <t/> element
> 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
> 'new')"?
> 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
> be said.
>    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
> calculations"?
> 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...
> - This might become clearer later, but at this stage it's not
> clear what 'positions' are.
> - Apart from adding complexity I'm not sure what forward
> delete is buying us vs. backspace.
> 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.
> - Ah, OK. So you do require normalisation here - you need to
> say which type is required.
> - This then forbids normalisation again.
> - 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.
> - "A single UTF-8 encoded character equals one code point" -
> this isn't true, is it?
If we instead say
"A single UTF-8 encoded Unicode Character equals one code point."
Is true, and then we need to define Unicode Character as the Character 
concept used in the Unicode standard.
And maybe a note saying that "Note that some visible characters are 
composed of more than one Unicode Character."

This is as far as I got for now.

> /K

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

More information about the Standards mailing list