[Standards] XEP-0301 0.5 comments [Sections 6 and beyond]

Mark Rejhon markybox at gmail.com
Tue Jul 24 16:58:47 UTC 2012

> On Tue, Jul 24, 2012 at 4:13 AM, Gunnar Hellström <
> gunnar.hellstrom at omnitor.se> wrote:

 <GH>I thought the "approximately" to mean something much more close to 700
> ms. I thought you wanted it just because of granularity of timers and that
> there is no need to be very precise. If you let it go down to 300 ms, you
> may get problems with bandwidth and servers, if you let it go up over one
> seconds you miss occasionally the usability goals for good real-time text
> according to ITU-T F.700/F.703.
> I do not usually regard 300 to be approximately 700. It would be strange
> to need to put a figure on it, but it could be "The interval should not
> vary more than 20%."

-- Your interpretation is correct too.  "approximately" can mean something
much closer to 700ms.  The interpretation is quite flexible, so there is a
lot of interpretations.
-- I wonder if you may have misinterpreted me.  The key word is "average".
 The math of (0.3 + 1.0 + 0.4 + 1.1) / 0.7 = an average of 0.7.  Thus, this
is acceptable, and no more harmful to XMPP servers than (0.7 + 0.7 + 0.7 +
0.7) / 0.7 = average of 0.7 ....   Same harmlessness for (1.4 + 0.0 + 1.4 +
0.0) = an average of 0.7.   Besides, network conditions sometimes forces
these variabilities, anyway.
-- If we needed to be fully technical about it, we could theoretically
mention an averaging window (I'd say, a window of approximately 5 seconds
is quite reasonable.  For example, an average of 0.7 seconds over the last
5 seconds).  But I don't think we need to be this strict about intervals.
 Again, the XMPP people are not the SIP people.
-- It's worth mentioning it is harmless to XMPP servers to have an instance
of a coupling (i.e. 2 <message/> stanzas transmitted simultaneously and
almost simultaneously).  It happens all the time in XMPP anyway, prescence
updates, chat states, and short messages -- it happens frequently, and it's
not uncommon for clients to sometimes occasionally send five stanzas (even
ten) in less than one second (for different purposes, like prescence
updates, disco queries, chat state, message being sent) -- unrelated to
real-time text.  It is sustained flood (a hundred of stanzas all at once)
that starts becoming unreasonable.
-- The key word is "average", so it was not meant to suggest an average of
less than 300ms, even if pairs of stanzas might chunk together to less than
-- I am pretty certain that even the XSF people agree with me here, that
they are not picky over 0.1 second differences, as long as the average
remains unaffected.
-- XMPP is not strict-synchronous technology like SIP, where delays in XMPP
is just simply graceful degradation that is often not noticed in instant
messaging, while delays in SIP can kill a voice call.  Thus, varabilities
in intervals are not critical.   XMPP is a higher-level protocol layer that
does not specify timing tolerances.
-- I think I will replace the word "approximately" with the word "average",
or say "the default average should be approximately..."
-- In case you ask about interference with <w/> elements -- you can use
less Wait Intervals (<w/> elements) when the <rtt/> is buffered for a
shorter period and transmitted sooner, and more Wait Intervals (<w/>
elements) when the <rtt/> is buffered longer and transmitted later.  It
continues to lead to smooth playback at the recipient end.
-- Network protection or congestion behaviours tend to generally come ahead
when there's a period of sustained rapid flow (i.e.100+ XMPP stanzas all at
once) -- which isn't what we're doing at all here.  Even so, sometimes it's
a way higher limit on a fast server in less loaded conditions (i.e. 5000+
XMPP stanzas).  Or just simply rate-limiting at weak triggers at 10 XMPP
stanzas, etc.   So, that occasional doubling to tripling up of stanzas is a
non-issue (i.e. 2 or 3 stanzas sent consecutively at once)

It is worth pointing out that some people outside of XMPP may be a little
nervous about timing of intervals, because of a large debate about
transmission intervals amongst the SIP people when standardizing older
real-time text technologies RFC2793 / RFC4103 / RFC5194  (RFC2793 is 12
years old).  The nature of XMPP is not as synchronous as SIP, and interval
timing is less critical than it was for SIP.  Historically, the XMPP people
have not made a huge fuss about 0.1 second differences -- unlike the SIP
people when the real-time text RFC's were first standardized more than ten
years ago.

In summary, the good people at XSF may express concern about the average
interval itself ("I'm wondering if 0.7 second too frequent?"), but I know
they do not generally care about occasional doubling-up or tripling-up of
stanzas simultaneously (in the viewpoint of "bad, bad, that fraction-second
variability is bad, bad!" ... "bad, bad, that quick pair of consecutive
stanzas is bad, bad!") -- it happens anyway in regular XMPP without this
protocol -- especially in clients that implements lots of XMPP protocols.
It's a high bandwidth / high average rate that's more discouraged than
random doubling-up of stanzas sent less than 0.1 second apart.... I
repeatedly brought up this topic here in the mailing list (including
dedicated threads!) and it just confirms what is already known about XMPP's
stance about intervals.

Opinions welcome from unbiased people who have not gone through the
experience of a fierce debate a decade ago -- regarding a more synchronous
technology -- during an era of lower bandwidth -- and slower servers.  The
0.1 second variances doesn't matter here.

                 Perhaps I could split it into a "5.1. Business Rules"
> section (ala XEP-0085) but I'm not sure that this is appropriate.
> Alternatively, I can add it as a "6. Business Rules" (bumping
> Implementation Notes as a section 7)
> Peter, David, et cetra from XSF, any comments?
> <GH>All of chapter 6 contains items that touch protocol, and here and
> there contain rules. So, I think we can safely call all of 6 something
> else. I find "Business rules" a bit strange selection of words for this
> technical area. How about "Application details".
> Are there any habits in XSF already for such sections?

Section 6.6 of XMPP Author Guidelines recommend the phrase "Business Rules":
Also, I doublechecked - google search of XMPP specs show it's common:

So, it seems the habit is frequently the name "Business Rules".   Renaming
"Implementation Notes" won't solve the problem, because Kevin wants me to
bump it higher upwards in the specificatio. This would almost certainly
necessitate a new section between "5. Discovering Support" and "6.
Implementation Notes".   XEP-0085 uses "5.1 Business Rules", as an example.

[Change Made]
>> Beginning now says *"It is possible for sender clients to implement
>> [[[Message Reset]]] as the only method of transmitting changes to a
>> real-time message."  *Although it already explains why it's discouraged,
>> I've now removed the word "may" to reduce the permissive-sounding tone.
> <GH>I earlier proposed another title for this section. Calling it "Basic
> real-time text, it may attract interest from implementors.
> Maybe "Using 'reset' for all transmissions.

The attraction of interest doesn't seem harmful in this case because I
already point out the disadvantages and people can clearly see that it
could consume bandwidth -- it makes people realize that XEP-0301 is quite
flexible from basic real-time text all the way to complicated real-time
text.  XEP-0301 is one of the top 20 biggest biggest XEP's (the top 5%) so
this short mention of how tiny a subset of XEP-0301 can work (with certain
disdvantages that make it unsuitable for many purposes), is quite

-I think the title is good -- though I am open to changing the title, but
reasonbly self-explanatory titles are generally preferred (even to people
who don't know what a Message Reset is yet).  The Table of Contents needs
to be reasonably comfortable to read.  Comments from others?
-- In addition, I'm open to adding more text to discourage the usage (than
the edit I already did).  This is preferred over renaming this section.
 Comments from others?

>> 6.4.4 is useful if it's not humans generating real-time text.  For
>> example transcription bots, gateways, etc.  So it's quite simple/useful to
>> have append-only real-time text (and you can still do key press intervals,
>> if needed, unless you're outputting fully-transcribed words one full word
>> at a time)
> <GH>I suggest to delete the second paragraph of 6.4.4. It tries to
> reinstate the functionality you lost by following the simple rule of the
> section, and ends up open ended if statements. I can imagine other ways to
> solve the mid message editing, but I think it is out of scope. By
> mentioning that you lose keypress intervals you may also give the
> impression that that is for all of 6.4.4, but it is only for that described
> method to do mid-message editing anyway in a method intended to not have
> that functionality.

A major implementer (>100 million users on their chat system) specifically
asked about this.
It's using append-only real time text (with key press intervals) during
normal typing, but following "Basic Real-Time Text" whenever doing
mid-message editing.   I find that this is perfectly reasonable use of
XEP-0301, and the behaviour is compatible all the way to version 0.0.2 of
the spec -- it's just simply creative use of message resets to simplify
mid-message editing, without losing key press intervals 99%+ of the time
(Because 99%+ of the time, people will be typing at the end of text instead
of the middle of the message.).   You get almost the best of both worlds --
key press intervals, and simpler sender implementation.   The disadvantages
ONLY occur during mid-message editing.

As a result, I strongly believe it is not appropriate to delete this
paragraph, but it can be appropriate to rewrite this paragraph to be more

[Change Made]
>> *"This provides immunity to variable network conditions, since the
>> queueing action will smooth out incoming transmission (e.g. receiving new
>> <rtt/> while still processing a delayed <rtt/>).
>> *Network issues can cause huge variability in transmission interval.
>> -- The sender may be sending <rtt/> elements on a 0.7s, 0.7s, 0.7s, 0.7s,
>> 0.7s
>> -- The recipient may be receiving <rtt/> elements delayed 0.9s, 1.3s,
>> 1.5s, 0.0s, 0.0s  (due to network conditions)
>> This results in stall-surge behaviours of real-time text that need to be
>> smoothed out during playback, for the best user experience while preserving
>> key press intervals.
>> [snip]
> <GH>Yes, the speeding up sentence is very important. It is better to skip
> displaying keypress intervals occasionally and get back to acceptable
> latency (<2 seconds end to end ) if there has been a delay.

Glad you agree.

> [Change Made]
>> "In addition, it is best to process <w/> elements asynchronously, to
>> avoid interfering with client operation."
>> [snip]
> <GH>This is a programming hint in the middle of protocol description. It
> might be better to delete it. It should be basic knowledge of communication
> programmers to not let the whole process hang on a timer. I see a small
> risk that the words "process asynchronously" are misunderstood for
> something complex in the transmission. Or at least cause extra wondering
> time before it is figured out that it is an internal hint.

Good point.  Will await Kevin's response to the original email.

   <GH>MUC support is important. It can be used as the multi-party bridge
> for XEP-0301 in multi-party multimedia calls, where typing and reading
> participants must have the same right to participate in rapid exchange as
> the speaking participants.
> In such situations it is mainly one speaker at a time that transmits
> real-time text, so the load considerations are not terrible, but are there.
> People without rtt have a tendency to send short incomplete phrase parts
> often to compensate for the lack of rtt, so in reality, rtt will "only"
> increase the load by a factor of 4 or so.

Depends on implementation.  Don't forget to distinguish "Load Factor" from
"Message Rate Factor".
A factor 4 is a pretty safe figure, but, it's risky to even mention any
figures, without citing a good paper first.

Loading Factor: Server loading is not always linear with message rate.
 Sometimes adding an extra transaction only increases load factor slightly.
 (e.g. In a highly optimized server, 10 transactions in 10 seconds might
only consume 10% or 25% more resources than 5 transactions in 10 seconds --
because of optimizations done for active connections.)

Message Rate Factor: For situations of 4 <rtt/> per message, the
transaction rate factor can potentially increase by less than 2, if you
slipstream <rtt/> into existing stanzas that are sent anyway (e.g. XEP-0085
chat states), and also since in many XMPP implementations, several other
stanzas (e.g. prescence updates, queries, chat states, disco, etc.).
Using WireShark / Ethereal snooping, I've seen particularly chatty XMPP
implementations that send more stanzas during regular under-40-character
message chatting -- than a very basic implementation of XEP-0301.    So in
certain situations, a basic XEP-0301 implementation can actually have a
lower stanza rate than a very chatty non-XEP-0301 client that sends a lot
of background traffic.   (That's a funny situation, isn't it!)

So, one has to calculate "how much additional load" that XEP-0301
contributes to:
1. The existing background traffic in an XMPP client
2. Of this existing background traffic, the opportunities to slipstream
<rtt/> into those (e.g. stanzas transmitting chat states)
3. Server optimizations that make an additional transaction 'less
expensive' than the previous (non-linear load scaling)
4. Some clients are more "chatty" than others in background traffic.

So, there are situations where load factor could be well over 20x, but
there are situations where the load factor apparently is LESS than 1x when
compared to chatty implementations :-)

>> I made comments earlier.
>> Even when senders send to the full JID, recipients can just process
>> real-time messages based on bare JID.
>> This makes it simpler for implementers of clients to implement only a
>> single real-time message per chat window.
>> It is a significant user interface complexity concern to gain the
>> capability of multiple simultaneous real-time messages in the same chat
>> window user interface.
>> Also, it is intuitive behaviour because of "Keeping Real-Time Text
>> Synchronized" so a simultaneous login user switching computers, the
>> recipient would simply see their copy of the real-time message switch
>> instantly from the partially-composed message from the old system to the
>> partially-composed message from the active system.  (thanks to the Message
>> Reset feature of "Keeping Real-Time Text Synchronized".   Even further
>> enhanced if good resource locking is done, too.  This is acceptable UX
>> behaviour, as a login is meant (in 99%+ of cases) to only have one typist.
>> <GH>Just keep the last sentence and change to a should: "Clients should
> distinguish the <rtt/> streams (via full JID and/or via <thread/>) and keep
> multiple concurrent real-time messages in similar manner to Multi-User
> Chat <http://xmpp.org/extensions/xep-0301.html#multiuser_chat>."

This sounds like a good suggestion, though I have to stay away from RFC2119
normatives after section 5.  Unless I move MUC it to the new "Business
Rules" section, then the normatives are acceptable in a "Business Rules"
section, from my interpretation of XEP-0143.
However, I'll wait for other comments in this regards, as I'm waiting for
comments to my response about bare JID handling and XEP-0301.

I've managed to reduce the size of Interoperability Considerations
>> significantly (to the best of my ability), but there are several people
>> including actual implementers (outside the XMPP umbrella) that are
>> demanding this text be bigger than it is now.
>> [snip]
> <GH>I think this section has a suitable size now. It is true that we shall
> not dictate what to use on the SIP side, so your small change is
> appropriate. We can describe what is available and briefly some actions to
> do to interoperate with these implementations. More details can go
> elsewhere.

I now have a reference to the Real Time Text Taskforce (R3TF), so any
further Interop info can go there.  (And I encourage the creation of
interop specifications)

[Change Made] -- Good catch, I see the redundancy.
>> *"It is important for implementors to educate users about real-time
>> text".*
> <GH>It is rather the application information that should make this clear.
> We do not need to chase implementors out in the field to become teachers.
>  how about: "It is important for application information to educate
> users..."

[Change Made]
I've changed it to *"It is important for applications to educate users of
real-time text.*

10.1 - I think a sensible Privacy note would be to make RTT opt-in.
> [Comment]
>> That depends on the market.  Mainstream client? (opt-in)
>>  Accessibiltiy-market client? (opt-out)   Emergency mode?
>> I am in contact with different implementers who will pounce on me if I
>> suggest either direction (opt-in versus opt-out).
> <GH>This is the natural text communication. In my view Opt-in is not
> needed and not wanted, but I know others have different views. Let it be
> out of scope for this protocol specification.

I agree with Gunnar.
Kevin suggests opt-in, Gunnar suggests opt-out.  Multiply these views by a
dozen happening in private discussions.  Discover a few gray hairs on my
scalp.  I see strong merits in these views.  (e.g. emergency clients,
accessibility clients, etc.)   The implementation detail of opt-in versus
opt-out is beyond scope of XEP-0301, except making sure both sides interop
with each other.

In closing out a serious discussion, I humbly attempt at some relief humor:

Opt-in versus opt-out.
So beyond scope.
So beyond scope, it's on Mars.
So beyond scope, it's a long time ago, in a galaxy far, far away.
So beyond scope, it's a parallel universe, in a universe where physics does
not exist.
Sides stronger than matter versus antimatter.
Opt-in merges with opt-out.
A warp core breach is in progress.
Ejecting the warp core!

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120724/7bb00420/attachment.html>

More information about the Standards mailing list