[Standards] XEP-0301 0.5 comments

Kevin Smith kevin at kismith.co.uk
Wed Jul 25 09:06:34 UTC 2012

Sorry, your mail client seems to be doing strange things and not
marking up replies normally, so this is a bit garbled.

On Mon, Jul 23, 2012 at 7:46 PM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> wrote:
> On 2012-07-23 16:32, Kevin Smith wrote:
> == 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.

Seems better - how about:
Be possible to produce gateways to interoperate with other real-time
text protocols such as 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 ).

This is going to continue to be a contentious point, I think. My
reading is that RTT and XMPP can be used as accessibility tools, as
they can provide communication methods to the deaf - but RTT doesn't
itself address an accessibility with XMPP, as XMPP is already
accessible for the deaf. I wonder if "Useable as an accessibility
tool" would be a sensible header.

> 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
> definition.
> 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.

I don't feel so strongly about this that I'll jump up and down until
it's changed, but in both of your examples the expectation is that
'instantly' means 'as soon as is possible' (although the parking guard
should really have chosen a better word to use). In the case of RTT
there is a deliberate buffering taking place to slow down transmission
into packets to the order of one a second. I'm slightly concerned that
by saying 'instantly' so early in the spec we're then encouraging
people to continue reading, thinking that this will be
keypress-by-keypress transmission.

In any case - this is a minor point.

> 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.

Given that conversation often follows a question/answer model if the
encryption used is vulnerable under a CPA we probably have many other
issues as well.

> 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

I think this is an odd use of MAY, then - sending subsequent event
attributes isn't really 'truly optional', but is one of two possible
transmission models. I think what it's trying to say is that rtt
update elements don't contain event attributes, but this isn't what
comes across, to me.

> - "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."

My concern here is the lack of precision about normalisation is
worrying me. I'm not yet convinced that nothing's going to change
composition anywhere important - and one code point (unicode
character) in one place could be more than one code point (unicode
character) elsewhere. I'm feeling quite uncomfortable about the effect
this will potentially have on interoperability - and I think it could
easily be solved by saying "before calculating the rtt transforms to
send the sender must apply normalisation to the string and before
applying the transformations to the rtt buffer the recipient must
apply normalisation to them, where we pick one of the normalisation
types and stick with it. The other option suggested to me when I was
asking people about the effect this would have on interop was to
require RTT to include what normalisation is used, so the sender would
send an update with normalisation=NFKC or whatever.


More information about the Standards mailing list