[Standards] Review: XEP-xxxx: In-Band Real Time Text - Point 2, the need.
gunnar.hellstrom at omnitor.se
Mon Feb 28 19:24:30 UTC 2011
You made a thorough review and listed a rich set of valuable comments.
A key point is your no 2, where you say that you have been into solving
the need to get more real-time-like transmission into XMPP.
So you recognize the need. So do I.
It is good for efficient communication in text to transmit text
time-sampled or so, instead of collecting it until a special action for
transmission is made by the user.
You had your <fragment> solution, but apparently you did not standardize
it. Here is the good initiative to standardize a solution for that
functionality need, so that it can become beneficial for all. So, let us
work on the proposal and your points and see if we can recommend
suitable changes so that you also see it get in shape for acceptance.
In your point 2 you also say that you think the proposal looks more
complex than what you had. It may be because it contains a few more
functions that are found practical and needed for good usability.
Such functions are for example the time distribution of the display to
avoid jerkiness, and the opportunity to erase and edit already
The coming discussion may come up with less complex solutions for the
same or similar functions, or an agreement that they are valuable and
acceptable as they are.
I want to stop here to check that we are on the same line so far.
Kevin Smith skrev 2011-02-28 13:02:
> At its recent meeting, the XMPP Council decided not to accept
> http://xmpp.org/extensions/inbox/realtimetext.html as an Experimental
> XEP, not because of the feature it provides, but because they felt
> there were shortcomings in this proposal. At the time, I promised to
> start a discussion here, on the premise that community discussion will
> either lead to updates to the proposal and it could be resubmitted, or
> that another approach would present itself. My comments on the
> proposal follow, in no particular order or clarity.
> 1) This is a huge XEP for a relatively simple feature - I copy/pasted
> the non-boilerplate content into `wc` and ended up with ~=11,600
> words. This is a concern (although not a reason to avoid publication
> on its own, it is daunting).
> 2) This is a fairly client-complex solution to the problem. Some years
> ago, I also needed to solve this problem, and deployed a very simple
> "Send<message ...><fragment>I'm not done typing this
> messa</fragment></message> every so often" protocol that seemed to
> work fine. It may be that this approach is unsuitable for the general
> case, but given the relative complexities of the two approaches, this
> needs to be discussed (and possibly rejected) as I'd far prefer a
> simple solution than a complex one.
> 3) Niggle: "Although real-time text benefits everyone in many
> situations" - I don't see any support for the 'everyone' in this
> 4) Goal "Make it easy for developers/implementors to implement Real
> Time Text in steps, with a minimum of code." may not be being met (see
> 5) Goal "Allow multiple modes of chat, including traditional IM user
> interface, split-screen chat, and other modes." seems like a UI
> feature, not a protocol feature.
> 6) Goal "Meet the quality requirements for real-time text. This is
> specified in ITU-T F.703  with an end-to-end delay of less than two
> seconds and transmission loss of less than 0.2%." - this seems to
> primarily be a feature of the networks and servers involved, rather
> than this protocol.
> 7) 2.3 Server Performance - I'm picking this out over the other cases
> for no good reason. Quite a lot of this XEP sounds like it's comments
> to Council justifying acceptance, rather than a part of the
> specification. I'd have thought that moving large amounts of this into
> a trailing Implementation Notes section would make it read better.
> 8) 2.4 Real-Time Message Editing - isn't half of this just repeating
> the introduction and AIM advert from the start of the document?
> 9) 2.6 Multi-User Chat. This needs a great deal of care, as the stanza
> amplification possibilities for large rooms are horrid. I accept that
> this has a big experimental warning on the paragraph, but feel it
> should be noted.
> 10) 2.7 User Interface Considerations. I think how to design a UI is
> largely down to the reader and doesn't belong in Requirements,
> although I'm not opposed to something in Implementation Notes.
> 11) 3.1 Functional Goals of the Specification. Another set of goals?
> 12) 3.2 "Clients that do not support real-time text will only receive
> the full message at once" - they'll receive everything, they'll only
> understand the full message body.
> 13) 3.2 "SHOULD show the text immediately" - this sounds like an odd
> thing to have in a protocol spec. What does 'immediately' even mean
> here? Are we saying that the client needs to skip any other processing
> it needs to do to render these data?
> 14) 3.2 "For senders, the default interval SHOULD be 1 second (1000
> milliseconds)" - I don't think this is required for interoperability,
> so RFC2119 language seems inappropriate here. I think we probably want
> a reference to a suggested period in Implementation Notes or similar.
> 15) 3.3 "There MAY also be multiple<rtt> elements in a single
> <message>" - I'm not sure why you'd want to do this, and it does add
> client complexity.
> 16) 3.3 msg/seq Attributes. This says that the attributes should be
> incremented, but not the magnitude of the delta (I assume 1).
> 17) I'm not convinced by the need for both msg and seq, given later
> comments about XMPP compliance (and I note that the simple protocol in
> comment (2) does away with the need altogether).
> 18) General - all the protocol outlined in the XEP is illegal, as it's
> happening in the jabber:client (and jabber:server) namespaces. The new
> stanza children need to be namespaced away.
> 19) 3.3.3 "Recipients MUST be able to process type='reset' when
> transmitting<rtt> with type='reset'" I don't follow the requirement
> 20) A thought - how does this interplay with XEP-0258? (I suspect that
> many people write messages first, and then label them). This is just
> an interesting aside.
> 21) 3.4 Use of<html>. I note that the simple protocol from (2) can
> trivially support<html> elements.
> 21) 3.5.2 should probably be clarified that 'empty' means 'with no
> text child' or such, so that a reader doesn't believe that they may
> omit the required attributes.
> 22) 3.5.3 Didn't we earlier read that it was ok to include many<rtt> elements?
> 23) 3.5.6 "In evaluations of relative values of attributes, values of
> counters recently wrapped around shall be considered higher than those
> approaching its maximum value." If we're going to say something like
> this, we need to be clear what it means. When has a client 'recently
> wrapped around'?
> 24) 3.6 Error Recovery. Messages can get lost, certainly, (although
> -0198 mitigates significantly), but I'm not sure where the assertion
> about overloaded servers comes from. Servers that deliver messages out
> of order are incompliant, and we should file bug reports against them
> so the authors can know about it and fix it, rather that writing
> (complex) protocol around this. For the little it's worth, I don't
> know of any current mainstream servers delivering messages out of
> sequence. I note, again, that the simple (2) protocol is not subject
> to the problems that this section addresses.
> 25) 3.6.1 You have to try pretty hard to get duplicate messages
> through, but it is possible.
> 26) 188.8.131.52 This has a SHOULD on processing msg, while earlier it was
> OPTIONAL (I assume you mean OPTIONAL, I don't believe NOT REQUIRED is
> covered by RFC2119).
> 27) 3.6.3 "a client MUST immediately pause updating" - this doesn't
> really need a MUST, there's no requirement for interop here.
> 28) 184.108.40.206 Why is this OPTIONAL? It sounds like an interop requirement.
> 29) 220.127.116.11 Given in-order delivery, I don't think this one's necessary.
> 30) 3.6.4 Here you're using 2119 in a section about UI, in the middle
> of the Protocol section of the document, and I've no idea what the
> Google advert is doing in there.
> 31) 3.7 Is XEP-0020 the appropriate negotiation method here? I'd have
> thought negotiating a simple Jingle session would be more appropriate?
> 32) 18.104.22.168.3 The right way of querying for support will be disco/caps.
> 33) 3.8.3 Some clarification of what a message position is would be
> beneficial here.
> I'm cutting off the blow-by-blow review here, as I don't have more
> time to spend on this, but hopefully this will start sufficient
> discussion to work out what the next steps are.
More information about the Standards