Version 1.6.1 of XEP-0198 (Stream Management) has been released.
Abstract:
This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including
features for stanza acknowledgements and stream resumption.
Changelog:
Clarify SASL2 and BIN
Version 1.6 of XEP-0198 (Stream Management) has been released.
Abstract:
This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including
features for stanza acknowledgements and stream resumption.
Changelog:
Specify error condition
Version 1.5.4 of XEP-0198 (Stream Management) has been released.
Abstract:
This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including
features for stanza acknowledgements and stream resumption.
Changelog:
Mark 'h' element as x
On Mittwoch, 25. Juli 2018 15:44:02 CEST Guus der Kinderen wrote:
> Changelog date is off by a year, I think?
Well spotted. Will fix.
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabbe
Changelog date is off by a year, I think?
On Fri, 6 Jul 2018 at 09:18, Jonas Wielicki wrote:
> Version 1.5.3 of XEP-0198 (Stream Management) has been released.
>
> Abstract:
> This specification defines an XMPP protocol extension for active
> management of an XML stream between two XMPP entities
Version 1.5.3 of XEP-0198 (Stream Management) has been released.
Abstract:
This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including
features for stanza acknowledgements and stream resumption.
Changelog:
Improve the note abou
Version 1.5.2 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements and stream resumption.
Changelog: Send 'a' element be
Version 1.5.1 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements and stream resumption.
Changelog: Fix example syntax
Version 1.5 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements and stream resumption.
Changelog: [See revision history
On 5/22/12 3:20 PM, Matt Miller wrote:
>
> On May 22, 2012, at 15:11, Matthew Miller wrote:
>
>>
>> On May 22, 2012, at 15:10, Peter Saint-Andre wrote:
>>
>>> On 5/22/12 3:08 PM, Matthew Miller wrote:
On May 22, 2012, at 14:58, Peter Saint-Andre wrote:
> On 5/21/12 1:21 AM,
On May 22, 2012, at 15:10, Peter Saint-Andre wrote:
> On 5/22/12 3:08 PM, Matthew Miller wrote:
>>
>> On May 22, 2012, at 14:58, Peter Saint-Andre wrote:
>>
>>> On 5/21/12 1:21 AM, Philipp Hancke wrote:
On Thu, 26 Apr 2012, Philipp Hancke wrote:
> old thread alert...
>
>
On 5/22/12 3:08 PM, Matthew Miller wrote:
>
> On May 22, 2012, at 14:58, Peter Saint-Andre wrote:
>
>> On 5/21/12 1:21 AM, Philipp Hancke wrote:
>>> On Thu, 26 Apr 2012, Philipp Hancke wrote:
>>>
old thread alert...
> Version 1.3 of XEP-0198 (Stream Management) has been released.
>>
On May 22, 2012, at 14:58, Peter Saint-Andre wrote:
> On 5/21/12 1:21 AM, Philipp Hancke wrote:
>> On Thu, 26 Apr 2012, Philipp Hancke wrote:
>>
>>> old thread alert...
>>>
Version 1.3 of XEP-0198 (Stream Management) has been released.
>>>
>>> I implemented 0198 for s2s and am in general
On 5/21/12 1:21 AM, Philipp Hancke wrote:
> On Thu, 26 Apr 2012, Philipp Hancke wrote:
>
>> old thread alert...
>>
>>> Version 1.3 of XEP-0198 (Stream Management) has been released.
>>
>> I implemented 0198 for s2s and am in general quite happy with it. Some
>> notes I wrote down while implementin
On Thu, 26 Apr 2012, Philipp Hancke wrote:
old thread alert...
Version 1.3 of XEP-0198 (Stream Management) has been released.
I implemented 0198 for s2s and am in general quite happy with it. Some notes
I wrote down while implementing this. Thanks Dave for listening to my
complaints and th
old thread alert...
Version 1.3 of XEP-0198 (Stream Management) has been released.
I implemented 0198 for s2s and am in general quite happy with it. Some
notes I wrote down while implementing this. Thanks Dave for listening to
my complaints and thanks Matthew for writing mod_smacks which was
Version 1.3 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements and stream resumption.
Changelog: [See revision history
Version 1.2 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements and stream resumption.
Changelog: Simplification based
Version 1.1 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements, stream resumption, and throttling notifications.
Chang
Version 0.10 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements, stream resumption, and throttling notifications.
Chan
Version 0.9 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements, stream resumption, and throttling notifications.
Chang
On 4/10/09 1:10 AM, Robin Redeker wrote:
> On Thu, Apr 09, 2009 at 07:19:11PM -0500, XMPP Extensions Editor wrote:
>> Version 0.8 of XEP-0198 (Stream Management) has been released.
>>
>> Abstract: This specification defines an XMPP protocol extension for active
>> management of an XML stream betwe
On Thu, Apr 09, 2009 at 07:19:11PM -0500, XMPP Extensions Editor wrote:
> Version 0.8 of XEP-0198 (Stream Management) has been released.
>
> Abstract: This specification defines an XMPP protocol extension for active
> management of an XML stream between two XMPP entities, including features for
Version 0.8 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements and stream resumption.
Changelog: [See revision history
On 4/7/09 7:52 AM, Peter Saint-Andre wrote:
> On 4/7/09 12:03 AM, Fabio Forno wrote:
>> On Tue, Apr 7, 2009 at 3:05 AM, Peter Saint-Andre wrote:
>>
S:
It isn't perfect but it can work for most of the cases.
>>> Agreed. But what is the purpose of max="n" here?
>> It could be used to
On 4/7/09 12:03 AM, Fabio Forno wrote:
> On Tue, Apr 7, 2009 at 3:05 AM, Peter Saint-Andre wrote:
>
>>> S:
>>>
>>> It isn't perfect but it can work for most of the cases.
>> Agreed. But what is the purpose of max="n" here?
>
> It could be used to adjust the number of maximun number of outstandi
On Tue, Apr 7, 2009 at 3:05 AM, Peter Saint-Andre wrote:
>>
>> S:
>>
>> It isn't perfect but it can work for most of the cases.
>
> Agreed. But what is the purpose of max="n" here?
It could be used to adjust the number of maximun number of outstanding
packets (When throttling it makes sense to
On 3/31/09 6:07 AM, Fabio Forno wrote:
> On Tue, Mar 31, 2009 at 3:23 AM, XMPP Extensions Editor
> wrote:
>> Version 0.7 of XEP-0198 (Stream Management) has been released.
>>
>> Abstract: This specification defines an XMPP protocol extension for active
>> management of an XML stream between two
On Tuesday 31 March 2009 12:45:22 Fabio Forno wrote:
> On Tue, Mar 31, 2009 at 6:31 PM, Dave Cridland wrote:
> >> Just realized: the max number of unacked stanzas could be used in
> >> order to prevent throttling and negotiate the rate with server...
> >
> > That sounds curiously interesting.
>
>
On Tue, Mar 31, 2009 at 6:31 PM, Dave Cridland wrote:
>> Just realized: the max number of unacked stanzas could be used in
>> order to prevent throttling and negotiate the rate with server...
>
> That sounds curiously interesting.
The present spec already does some rate limitation, since any clie
On Tue, Mar 31, 2009 at 6:29 PM, Dave Cridland wrote:
>
> Technically speaking, those aren't stanzas, which might answer the question.
>
And it confirms what I had in mind ;)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Tue Mar 31 17:29:10 2009, Fabio Forno wrote:
Just realized: the max number of unacked stanzas could be used in
order to prevent throttling and negotiate the rate with server...
That sounds curiously interesting.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
On Tue Mar 31 17:27:53 2009, Fabio Forno wrote:
Ok, so the just triggers an ack, and everything is bound to an
implicit sequence number bound to stanza count. It seems to work,
the
only thing to decide is whether to count r & a stanzas ;)
Technically speaking, those aren't stanzas, which mi
On Tue, Mar 31, 2009 at 6:27 PM, Fabio Forno wrote:
>
> Ok, so the just triggers an ack, and everything is bound to an
> implicit sequence number bound to stanza count. It seems to work, the
> only thing to decide is whether to count r & a stanzas ;)
Just realized: the max number of unacked st
On Tue, Mar 31, 2009 at 5:57 PM, Justin Karneges
wrote:
>> wrote:
>> > C:
>> > C:
>> > C:
>> > C: (when S receives this element, it knows 'u' is 3)
>> >
>> > S:
[...]
> When the session is resumed, the server will state its last 'h' value. If the
> server had received all three message st
On Tuesday 31 March 2009 08:44:41 Fabio Forno wrote:
> On Tue, Mar 31, 2009 at 5:31 PM, Justin Karneges
>
> wrote:
> > C:
> > C:
> > C:
> > C: (when S receives this element, it knows 'u' is 3)
> >
> > S:
>
> Yep but if the client doesn't receive the h='3' the only safe decision
> is to to res
On Tue, Mar 31, 2009 at 5:31 PM, Justin Karneges
wrote:
>
> C:
> C:
> C:
> C: (when S receives this element, it knows 'u' is 3)
>
> S:
Yep but if the client doesn't receive the h='3' the only safe decision
is to to resend all the 3 messages, while any number of them could
have been already
On Tuesday 31 March 2009 08:24:47 Fabio Forno wrote:
> On Tue, Mar 31, 2009 at 5:17 PM, Justin Karneges
>
> wrote:
> > Proposed change: Don't send 'u' over the wire anymore. The value shall
> > be derived by the number of stanzas sent, starting from 0 (no stanzas
> > sent yet).
> >
> > C:
> > C:
On Tue, Mar 31, 2009 at 5:17 PM, Justin Karneges
wrote:
> Proposed change: Don't send 'u' over the wire anymore. The value shall be
> derived by the number of stanzas sent, starting from 0 (no stanzas sent yet).
>
> C:
> C:
>
> S:
>
> We'd still have and ack elements. They'd just only ever
On Tue, Mar 31, 2009 at 08:17:43AM -0700, Justin Karneges wrote:
> On Tuesday 31 March 2009 08:07:15 Fabio Forno wrote:
> > On Tue, Mar 31, 2009 at 4:05 PM, Peter Saint-Andre
[.snip.]
>
> Of course we don't want to require acks unless they are explicitly requested.
>
> Let's not veer too far
On Tuesday 31 March 2009 08:07:15 Fabio Forno wrote:
> On Tue, Mar 31, 2009 at 4:05 PM, Peter Saint-Andre
wrote:
> > I would prefer the sequence number to be a stanza count, but Justin
> > talked me out of it while I was making revisions. However, from the post
> > you've pointed to, he seems to
On Tue, Mar 31, 2009 at 4:05 PM, Peter Saint-Andre wrote:
> I would prefer the sequence number to be a stanza count, but Justin
> talked me out of it while I was making revisions. However, from the post
> you've pointed to, he seems to agree, so I'll fix that.
>
> As to sending after the stanza,
On 3/31/09 6:07 AM, Fabio Forno wrote:
> On Tue, Mar 31, 2009 at 3:23 AM, XMPP Extensions Editor
> wrote:
>> Version 0.7 of XEP-0198 (Stream Management) has been released.
>>
>> Abstract: This specification defines an XMPP protocol extension for
>> active management of an XML stream between two X
On Tue, Mar 31, 2009 at 3:23 AM, XMPP Extensions Editor wrote:
> Version 0.7 of XEP-0198 (Stream Management) has been released.
>
> Abstract: This specification defines an XMPP protocol extension for active
> management of an XML stream between two XMPP entities, including features for
> stanza
Version 0.7 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements and stream resumption.
Changelog: Removed pings (use XE
On Fri, Mar 20, 2009 at 1:22 AM, Fabio Forno wrote:
>> Of course, I still question the need for 'u' at all if we're doing it like
>> this.
>
> Now I remember: for limiting latency it's better to allow a window of
> unacked stanzas (on slow mobile connections each roundtrip can be 2-3
> seconds)
On Thu, Mar 19, 2009 at 05:03:29PM -0700, Justin Karneges wrote:
> On Thursday 19 March 2009 16:52:14 Robin Redeker wrote:
> > Thats the same as this IMO:
> >
> > C:
> > C:
> > C:
> > C:
> > C:
> >
> > S:
>
> That's not reliable though. What you want to do is this:
>
> C:
>
On Fri, Mar 20, 2009 at 1:12 AM, Justin Karneges
wrote:
> 'h' would stay outside of the stanza, since you need to be able to send it
> without having to send a stanza. And 'u' could always be in the stanza,
> since you'd never use it without having sent a stanza at the same time.
>
> C:
>
> S:
On Thursday 19 March 2009 17:02:38 Fabio Forno wrote:
> On Fri, Mar 20, 2009 at 12:49 AM, Justin Karneges
>
> wrote:
> > I don't see much value in allowing the sequence number to be out of sync
> > with the stanza count, so how about we just make them match? The value
> > of 'u' could always be t
On Thursday 19 March 2009 16:52:14 Robin Redeker wrote:
> Thats the same as this IMO:
>
> C:
> C:
> C:
> C:
> C:
>
> S:
That's not reliable though. What you want to do is this:
C:
C:
C:
C:
C:
C:
C:
C:
That way, if the connection dies in the middle somew
On Fri, Mar 20, 2009 at 12:49 AM, Justin Karneges
wrote:
>
> I don't see much value in allowing the sequence number to be out of sync with
> the stanza count, so how about we just make them match? The value of 'u'
> could always be the number of stanzas transmitted so far, and we wouldn't
> send
On Thu, Mar 19, 2009 at 04:35:17PM -0700, Justin Karneges wrote:
> On Thursday 19 March 2009 16:08:00 Robin Redeker wrote:
> > On Thu, Mar 19, 2009 at 01:49:31PM -0500, XMPP Extensions Editor wrote:
> > > Version 0.6 of XEP-0198 (Stream Management) has been released.
> >
> > My main problem is to u
On Thursday 19 March 2009 15:48:37 Fabio Forno wrote:
> Yep, missed it in the example, but there more cases. Just suppose
> is lost before arriving to the server and the previous
> message not. The message is processed, and now the server can't send
> back the u=2 ack since it never received the
On Thursday 19 March 2009 16:08:00 Robin Redeker wrote:
> On Thu, Mar 19, 2009 at 01:49:31PM -0500, XMPP Extensions Editor wrote:
> > Version 0.6 of XEP-0198 (Stream Management) has been released.
>
> My main problem is to understand the purpose of being able to
> include u _and_ h in a or elemen
On Thu, Mar 19, 2009 at 01:49:31PM -0500, XMPP Extensions Editor wrote:
> Version 0.6 of XEP-0198 (Stream Management) has been released.
My main problem is to understand the purpose of being able to
include u _and_ h in a or element. If each has to be
answered with an OR it seems a bit redund
On Thu, Mar 19, 2009 at 11:29 PM, Justin Karneges
wrote:
> On Thursday 19 March 2009 15:21:12 Fabio Forno wrote:
>> I see one issue for perfect stream reliability: stanza suplication. An
>> example:
>>
>> [C]
>> [C]
>>
>> [S]
>>
>> server sends back but the connection dies ---
>>
>> cli
On Thu, Mar 19, 2009 at 11:27 PM, Justin Karneges
wrote:
> It's also useful to ping the connection when there's otherwise no traffic. Of
> course you could just use the ack packets with a sequence number for this,
> but having a separate element seemed cleaner.
but compressors like little entr
On 3/19/09 4:27 PM, Fabio Forno wrote:
> On Thu, Mar 19, 2009 at 11:21 PM, Fabio Forno wrote:
>> I see one issue for perfect stream reliability: stanza suplication. An
>> example:
>
> duplication of course ;)
Perhaps stream supplication, as in "please please please give me a
stream". ;-)
smim
On Thursday 19 March 2009 15:21:12 Fabio Forno wrote:
> I see one issue for perfect stream reliability: stanza suplication. An
> example:
>
> [C]
> [C]
>
> [S]
>
> server sends back but the connection dies ---
>
> client resumes the stream and the last ack is 1 ---
Nope: server indicate
On Thu, Mar 19, 2009 at 11:21 PM, Fabio Forno wrote:
> I see one issue for perfect stream reliability: stanza suplication. An
> example:
duplication of course ;)
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
On Thursday 19 March 2009 14:51:08 Fabio Forno wrote:
> Which is the value of having a and a stanza in
> addition to stanzas besides the ability of sending back and
> error condition saying that packets are being throttled?
It's also useful to ping the connection when there's otherwise no traf
On Thu, Mar 19, 2009 at 7:49 PM, XMPP Extensions Editor wrote:
> Version 0.6 of XEP-0198 (Stream Management) has been released.
>
> Abstract: This specification defines an XMPP protocol extension for active
> management of an XML stream between two XMPP entities, including features for
> stanza
On 3/19/09 3:51 PM, Fabio Forno wrote:
> On Thu, Mar 19, 2009 at 7:49 PM, XMPP Extensions Editor
> wrote:
>> Version 0.6 of XEP-0198 (Stream Management) has been released.
>>
>> Abstract: This specification defines an XMPP protocol extension for active
>> management of an XML stream between two
On Thu, Mar 19, 2009 at 7:49 PM, XMPP Extensions Editor wrote:
> Version 0.6 of XEP-0198 (Stream Management) has been released.
>
> Abstract: This specification defines an XMPP protocol extension for active
> management of an XML stream between two XMPP entities, including features for
> stanza
On 3/19/09 12:49 PM, XMPP Extensions Editor wrote:
> Version 0.6 of XEP-0198 (Stream Management) has been released.
>
> Abstract: This specification defines an XMPP protocol extension for
> active management of an XML stream between two XMPP entities,
> including features for stanza acknowledgemen
Version 0.6 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements, pings, and stream resumption.
Changelog: [See revision
Version 0.5 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements, pings, and stream resumption.
Changelog: Removed recom
Version 0.4 of XEP-0198 (Stream Management) has been released.
Abstract: This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including features for
stanza acknowledgements, pings, and stream resumption.
Changelog: Added support
68 matches
Mail list logo
