Re: [Standards] XEP-0301 Session handling

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

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

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

[Standards] Advice on XEP-0301 Mass-Market Use Cases (if XEP-0301 added to Adium/Miranda within 12 months)

To the Stadards group, I bring up a question separate from the Session Handling. (many questions have already been answered -- thank you very much) *Scenario: *XEP-0301 real-time text gets added to a mainstream client such as Pidgin or Miranda within 12 months. *Question: *What is the simplest p

Re: [Standards] XEP-0301 Session handling

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

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

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

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

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

> > *[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

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

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/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

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

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

Re: [Standards] long specs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/27/12 4:02 PM, Peter Saint-Andre wrote: > On 2/15/12 1:07 PM, Peter Saint-Andre wrote: >> On 2/15/12 12:48 PM, Kurt Zeilenga wrote: > >>> On Feb 15, 2012, at 8:26 AM, Peter Saint-Andre wrote: > I'd be willing to work on this, but I want to

[Standards] Proposed XMPP Extension: PubSub Since

The XMPP Extensions Editor has received a proposal for a new XEP. Title: PubSub Since Abstract: This specification defines a publish-subscribe feature that enables a subscriber to automatically receive pubsub and PEP notifications since its last logout time. URL: http://xmpp.org/extensions/inb

Re: [Standards] Pubsub to atom mapping :)

On 2/28/12 1:56 AM, Sergey Dobrov wrote: > On 02/28/2012 06:36 AM, Peter Saint-Andre wrote: >> On 2/27/12 12:36 AM, Sergey Dobrov wrote: >>> The other thing here is linking: atom:link needs attributes "ref" and >>> "href", but href usually points to the atom feed at all and ref points >>> to the sp

Re: [Standards] Pubsub to atom mapping :)

On 02/28/2012 06:36 AM, Peter Saint-Andre wrote: > On 2/27/12 12:36 AM, Sergey Dobrov wrote: >> The other thing here is linking: atom:link needs attributes "ref" and >> "href", but href usually points to the atom feed at all and ref points >> to the specific entry in the feed by it's atom:id. Then,