Re: [Standards] XEP-0301 Session handling

2012-03-07 Thread Peter Saint-Andre
On 2/29/12 1:11 PM, Gunnar Hellström wrote: > Peter Saint-Andre skrev 2012-02-29 19:40: >> I really think that if you want to gateway between SIP and XMPP, you >> want to use Jingle. Such gatewaying was one of the core considerations >> for Jingle. Now, I haven't looked at RFC 4103 in quite a while

Re: [Standards] XEP-0301 Session handling

2012-02-29 Thread Gunnar Hellström
Peter Saint-Andre skrev 2012-02-29 19:40: I really think that if you want to gateway between SIP and XMPP, you want to use Jingle. Such gatewaying was one of the core considerations for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we can certainly write a spec that defines how

Re: [Standards] XEP-0301 Session handling

2012-02-29 Thread Peter Saint-Andre
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/28/12 11:28 PM, Gunnar Hellström wrote: > Returning to the initial question of this thread: Is there a common > way to indicate session start and session end. > > Peter Saint-Andre skrev 2012-02-29 04:20: >> Yes, but that doesn't necessarily mean

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Gunnar Hellström
Returning to the initial question of this thread: Is there a common way to indicate session start and session end. Peter Saint-Andre skrev 2012-02-29 04:20: Yes, but that doesn't necessarily mean you need an explicit negotiation protocol. Right. The first need I thought about can in fact be red

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre
On 2/28/12 8:15 PM, Mark Rejhon wrote: > > Hello, > > > That's a client configuration and UI issue, not a protocol issue. > > > Actually, we've found it is a very important long-term interoperability > issue -- please see my big email, we have plans to add RTT to multiple > open source cl

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon
Hello, > That's a client configuration and UI issue, not a protocol issue. > Actually, we've found it is a very important long-term interoperability issue -- please see my big email, we have plans to add RTT to multiple open source clients. We've explained several scenarios (i.e. a Year 2014

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre
Hi Florian! On 2/28/12 7:42 PM, Florian Zeitz wrote: > Am 29.02.2012 03:02, schrieb Peter Saint-Andre: >> On 2/28/12 6:13 PM, Mark Rejhon wrote: >>> *[To Discuss] Matter of negotiation of activation of RTT feature* >>> /However/, XEP-0085 doesn't answer the question of an appropriate >>> negotiati

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre
On 2/28/12 7:33 PM, Mark Rejhon wrote: > On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre > wrote: > > I'm suggesting that you use a model similar to XEP-0085 -- if the other > side advertises it (disco/caps), send the first message with some kind > of RTT

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Florian Zeitz
Am 29.02.2012 03:02, schrieb Peter Saint-Andre: > On 2/28/12 6:13 PM, Mark Rejhon wrote: >> *[To Discuss] Matter of negotiation of activation of RTT feature* >> /However/, XEP-0085 doesn't answer the question of an appropriate >> negotiation model for deciding whether or not to enable RTT for a cha

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon
On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre wrote: > I'm suggesting that you use a model similar to XEP-0085 -- if the other > side advertises it (disco/caps), send the first message with some kind > of RTT element. If the response comes back without an RTT element, don't > include any RTT

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre
On 2/28/12 6:13 PM, Mark Rejhon wrote: > > > On Tue, Feb 28, 2012 at 7:04 PM, Peter Saint-Andre > wrote: > > On 2/28/12 4:47 PM, Mark Rejhon wrote: > > [snip] > > > *Use Case Example #1:* > > Alice messages Bob. Alice enables real-time text by clic

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon
> > *[Answered] Matter of Simplifying XEP-0305 by removing its session > signalling* > When I wrote that, I meant XEP-0301, of course.

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon
On Tue, Feb 28, 2012 at 7:04 PM, Peter Saint-Andre wrote: > On 2/28/12 4:47 PM, Mark Rejhon wrote: [snip] > *Use Case Example #1:* > > Alice messages Bob. Alice enables real-time text by clicking a button. > > On Bob machine, when his software receives an element for the > > first time, the so

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre
On 2/28/12 4:47 PM, Mark Rejhon wrote: > I'm interested in feedback about session negotiation techniques, and > about simplifying XEP-0301 by removing the start/cancel attributes > (which are OPTIONAL) which are actually not currently used in any of the > several XEP-0301 implementations I have se

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Mark Rejhon
2012/2/28 Gunnar Hellström > Sometimes it is very helpful with a clear beginning and a clear end of an > XMPP text session. > For example if you are gatewaying to a SIP call, and want to cause a > hangup on the SIP side, or get an indication to the XMPP side when the SIP > side has closed the ses

Re: [Standards] XEP-0301 Session handling

2012-02-28 Thread Peter Saint-Andre
Hi Gunnar! On 2/28/12 4:07 PM, Gunnar Hellström wrote: > Sometimes it is very helpful with a clear beginning and a clear end of > an XMPP text session. Some people have thought so in the past: http://xmpp.org/extensions/xep-0155.html That was mainly developed for the purpose of end-to-end encry

[Standards] XEP-0301 Session handling

2012-02-28 Thread Gunnar Hellström
Sometimes it is very helpful with a clear beginning and a clear end of an XMPP text session. For example if you are gatewaying to a SIP call, and want to cause a hangup on the SIP side, or get an indication to the XMPP side when the SIP side has closed the session. * Question*: I wonder if th