You top-posted. Gotcha! :-) Now, since I need a discussion on feature negotiation:
On Thu, Mar 3, 2011 at 6:17 PM, Peter Saint-Andre <[email protected]> wrote: > Those are good questions, but I'm out of time for further discussion > until (probably) Tuesday. I'll let other folks on the list reply. Thanks Peter. Anyone? About negotiation protocol which I am considering removing from the spec: >>>> -- Simplify, change or remove protocol negotiation? >>>> LEANING: Undecided. I feel more discussion is needed. For now, I'll >>>> keep until I'm almost done with other things. >>> >>> I think we can cover almost all of the use cases with disco and caps. We >>> prefer not to design for use cases we don't know about or can only >>> imagine at this time. >> >> Yes, I agree. But help me out, based on my written concerns: How do I >> ensure that the feature is turned on BOTH ends (disallow >> unidirectional real time text) -- with with BOTH of the users' >> informed consent? It's a can of worms, of privacy issues and/or >> mis-sync of enabled RTT state. One idea is to temporarily remove negotiation as a pressing interop issue (let experimenters worry about that privately), and therefore leave negotiation out of the spec for this specific iteration of spec. -- However, some basic giudelines is needed to resolve the mis-sync of state (one end with RTT enabled, the other end with RTT disabled or refused becaues they don't want to send real time text), and also a proper future path for backwards compatibility with clients that do not support negotiation, if negotiation is later added. I'd like guidance on this. -- Also I would need to resolve interval concerns. For example, mobile devices might legitimiately need to ask the sender to slow down the rate, especially since RTT clients on LAN might use a minimum real time text buffering interval of 250ms (i.e. up to 4 XMPP messages a second) to keep latencies low. Due to fixed <message> overheads (even though RTT can be spread over as many messages as desired), the total bandwidth can more double if you send 4 XMPP messages a second, versus 1 XMPP message a second. An Iridium satellite link or congested satellite links (>2000ms ping) may prefer one XMPP message every 2-3 seconds, while LAN links running LAN XMPP servers may prefer a 100ms interval (up to 10 XMPP messages a second). Interval negotiation isn't absolutely necessary for interop if we choose a standardized value that meets the lowest common denominator, but the lowest common denominator is undesirable in other situations. There are situations where removing interval negotiation completely can be problematic. Imagine a satellite communications device (with interval set to 2000ms ) connecting to someone else on a high performance network (with interval set to 250ms). Then we now have an interoperability problem. Even in tests, I ran into issues using LAN-optimized intervals when running on a netbook running over an EDGE data connection. This is amplified even further when using even worse connections such as satellite or dial-up. Now, let's theoretically abandon feature negotiation (XEP-0020) and we communicate the following data through other XEP's such as disco (XEP-0030) and caps (XEP-0115). Should we only use disco, or only use caps, or do we need to use both? It appears I could communicate the information over caps, but since I may need to use XEP-0128 extended info, should I just stick with XEP-0020 and simplify it instead? (Just so I only need to refer to one other spec -- XEP-0020) Information that I think must be communcated for interoperability: - Boolean: Real time text feature exists - Number String: Interval value (For conflicting interval values, biggest interval value wins) Information that I think should be communicated: - Number String: Tier level (Level 2 to support delay codes and cursor movements) - Version of real time text that is supported Then in addition, I need a proper protocol that ensures that both ends enable real time text, to reduce unintentional unidirectional real time text, as well as privacy concerns. For a refresher, Secton 3.7 of my old draft of specification: http://www.realjabber.org/realtimetext.html (New website -- not much content yet) If I do not completely remove feature negotiation completely (only to put it back later to be able to cover common use cases), I'm trying to decide what combination of feature negotiate XEP-0020, disco XEP-0030, and/or caps XEP-0115 can be used to make the spec as simple as possible, while meeting sync and privacy concerns. I'm open to ideas. Thanks! Mark Rejhon
