It may be useful to include some note on how this would interact with XEP-0071 for XHTML-IM, if at all.
If the two can be used together, then I would imagine that any HTML formatting would be ignored when sending RTT, and only sent in a normal, full message stanza. And for the receiver, I would expect it to replace the received RTT with the XHTML-IM content when it arrives. -- Lance On Jun 27, 2012, at 11:57 AM, Mark Rejhon wrote: > On Wed, Jun 27, 2012 at 8:55 AM, Kurt Zeilenga <[email protected]> > wrote: > > Maybe one day we'll have virtually unlimited bandwidth everywhere... > > but that's simply not the case today and likely won't be the universally > > case for many decades (if ever). > > Even fast typing over real-time text, is still rate-limited to 1 stanza > > every interval (such as 700ms or 1 second) > > It's not how slow or fast the user types, it's how many RTTs stanzas are set > in addition to the IM stanzas as seen on the XMPP network in total. If we > assume every user has this extension enabled (which is the worse case, I > believe) > > We need to distinguish "extension enabled" from "extension active". > A chat client can advertise that it has audio/video support, but keep it > inactive until initiated by the user. > > When RTT is added to a mass-market client (note: AOL's AIM has real-time text > already) it would be something that can be initiated by the user, such as via > a button, i.e. containing the International RTT symbol -- www.fasttext.org > > It would be a very gradual process, very few RTT users at first (first in > slowly-increasing open source programs before it reaches a popular brand of > instant message program), so the XMPP network has many years to scale/adjust > to the needs. It's already scaled to meet the needs of in-band file and > avatar-image transfers, for example. RTT penetration into mainstream > clients is envisioned as a 10-year process. During this time, most of these > software will do stream-level encryption instead of stanza-level encryption, > so combined with the gradual scaling, it shouldn't be a big enough concern to > mention in the spec about recommending turning off RTT during stanza level > encryption. > > > The number of RTTs per IM likely depends on many factors, but I'm roughly > guessing there's somewhere between 1 and 10 RTTs per IM stanza. Even at 1, > we're basically doubling of the bandwidth demand. > > Given average instant message lengths of 40 characters, that sounds accurate. > Even with many layers of bubble-wrapping, it's still far less bandwidth than > video. > You can also 'fold' the real-time text in other stanzas you normally send, > such as Chat States, so subtract about 1 or 2 the total increase. > > > > In borderline situations, you could adjust transmission intervals to > > violate the recommended range 0.3s-1.0s (I only made that range a 'SHOULD') > > -- such as transmitting real-time text at 2 second intervals instead. > > You? as in the user? User's don't know what's wrong, or how to fix it. > Hell, they are likely to decrease the interval in hopes of getting an unfair > amount of the available bandwidth. > > No, no -- it's a software decision. > When I said "you", I meant the developer. Apologies for not being clear. > > Software be designed to automatically adjust the transmission interval to > automatically adapt to situations such as bandwidth, congestion, decide to do > flow control (acknowledgements), etc. You can do fancy flow control on > real-time text to run reduced-rate real-time text on an overloaded server. > So it's no longer the end of the world. > I even already mention this in section 10.2 Congestion Considerations: > http://xmpp.org/extensions/xep-0301.html#congestion_considerations > This should cover the situation when part of the chain of the real-time text > is 'expensive' (i.e. stanza level encryption slowing down real time text) > > > True congestion control should not be user driven, it should be code driven, > based on feedback from the network. It should be designed to promote 'fair' > allocation of bandwidth and congestion pain. > > That's what I said. :-) > > Sincerely, > Mark Rejhon
