Just a minor note -- due to several sudden private mails I am getting -- I need to point out something important:
On Sat, Jun 30, 2012 at 2:31 PM, Mark Rejhon <[email protected]> wrote: > I need some comments about existing protocol specification of XEP-0301 to > permit session-like behaviour of real-time text. > Right now, the current XEP-0301 specification permits the scenario to be > possible, *at the implementor's option* > The key phrase is "**at the implementor's option**" Implementors should be given the choice. I am only merely trying to make it "possible". You don't have to session-like behaviour. Your client can have RTT on at all times and send RTT by default when both ends advertise support. That's legal behaviour, too. But not all vendors want to do it that way. You don't have to "do what the other vendors does". I'm just making sure the spec doesn't /prevent/ implementation of session-like behaviour, by asking the following questions: QUESTIONS as follows: > 1. Are there other scenarios that XEP-0301 implementors want to see "made > possible", not currently possible with the current protocol? > 2. Are there other unresolved protocol gotchas from the above example > scenarios? > (i.e. high latency causing <rtt event='cancel'/> not to cause incoming > <rtt/> to stop for a while, causing client to think it's a new session > attempt? Guard delay needed? Does this warrant re-adding the <rtt > event='start'/> that was removed from the spec in the last revision? etc.) > Thank you so much :-) Mark Rejhon
