Re: [jdev] Server implementation query: State after SM resumption
sorry, I think I was unclear. I confused „restored“ with „reset“... "carbons state would not be restored“ should mean "carbons state would be restored“. In general, I think previous state would be the same as before resumption, so that clients don’t need to reestablish/renegotiate any state. > Am 15.03.2017 um 18:03 schrieb Christian Schudt : > > Hi, > > I think Openfire doesn’t support Stream Resumption yet, but I’ve implemented > Carbons in it and I think if it would support stream resumption, carbons > state would not be restored. > I.e. Carbons state would be the same as before. > > I guess any implementation would keep some stateful session object in memory > and when clients resume a stream, the new connection is just associated with > the old session (with the help of the SM-ID). > > Therefore any negotiated session state (e.g. Carbons or CSI) would be > unchanged after stream resumption, unless a developer explicitly resets any > state (which is discouraged by XEP-0198, see below). > > This is at least my opinion, because it feels like the most natural approach > a developer would probably develop it. > > Furthermore XEP-0198 clearly states: > > • The client SHOULD NOT resend presence stanzas in an attempt to restore its > former presence state, since this state will have been retained by the server. > • Both parties SHOULD NOT try to re-establish state information > > > Kind regards, > Christian > > >> Am 09.03.2017 um 21:17 schrieb Florian Schmaus : >> >> Given the latest discussions at council@/standards@ ([1] 5.) I think it >> is time for a short inquiry of XMPP server behaviour in the wild. Please >> answer the following questions: >> >> 1. What is the name of the server you develop? >> >> 2. Is the carbons state restored after a stream resumption (XEP-0198)? >> (yes/no/not implemented) >> >> 3. Is the CSI state restored after a stream resumption (XEP-0198)? >> (yes/no/not implemented) >> >> Your answers will help the XMPP community to get more informed overview >> of the currently deployed state of interaction between Stream Management >> and CSI, Carbons and other XEPs. >> >> Thanks for your time! >> >> - Florian >> >> 1: https://mail.jabber.org/pipermail/council/2017-March/004166.html >> >> >> >> ___ >> JDev mailing list >> Info: https://mail.jabber.org/mailman/listinfo/jdev >> Unsubscribe: jdev-unsubscr...@jabber.org >> ___ > > ___ > JDev mailing list > Info: https://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > ___ ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Server implementation query: State after SM resumption
Hi, I think Openfire doesn’t support Stream Resumption yet, but I’ve implemented Carbons in it and I think if it would support stream resumption, carbons state would not be restored. I.e. Carbons state would be the same as before. I guess any implementation would keep some stateful session object in memory and when clients resume a stream, the new connection is just associated with the old session (with the help of the SM-ID). Therefore any negotiated session state (e.g. Carbons or CSI) would be unchanged after stream resumption, unless a developer explicitly resets any state (which is discouraged by XEP-0198, see below). This is at least my opinion, because it feels like the most natural approach a developer would probably develop it. Furthermore XEP-0198 clearly states: • The client SHOULD NOT resend presence stanzas in an attempt to restore its former presence state, since this state will have been retained by the server. • Both parties SHOULD NOT try to re-establish state information Kind regards, Christian > Am 09.03.2017 um 21:17 schrieb Florian Schmaus : > > Given the latest discussions at council@/standards@ ([1] 5.) I think it > is time for a short inquiry of XMPP server behaviour in the wild. Please > answer the following questions: > > 1. What is the name of the server you develop? > > 2. Is the carbons state restored after a stream resumption (XEP-0198)? > (yes/no/not implemented) > > 3. Is the CSI state restored after a stream resumption (XEP-0198)? > (yes/no/not implemented) > > Your answers will help the XMPP community to get more informed overview > of the currently deployed state of interaction between Stream Management > and CSI, Carbons and other XEPs. > > Thanks for your time! > > - Florian > > 1: https://mail.jabber.org/pipermail/council/2017-March/004166.html > > > > ___ > JDev mailing list > Info: https://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > ___ ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
[jdev] Server implementation query: State after SM resumption
Given the latest discussions at council@/standards@ ([1] 5.) I think it is time for a short inquiry of XMPP server behaviour in the wild. Please answer the following questions: 1. What is the name of the server you develop? 2. Is the carbons state restored after a stream resumption (XEP-0198)? (yes/no/not implemented) 3. Is the CSI state restored after a stream resumption (XEP-0198)? (yes/no/not implemented) Your answers will help the XMPP community to get more informed overview of the currently deployed state of interaction between Stream Management and CSI, Carbons and other XEPs. Thanks for your time! - Florian 1: https://mail.jabber.org/pipermail/council/2017-March/004166.html signature.asc Description: OpenPGP digital signature ___ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___