Re: [jdev] Server implementation query: State after SM resumption

[Christian Schudt]

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

[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] Server implementation query: State after SM resumption

[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





signature.asc
Description: OpenPGP digital signature
___
JDev mailing list
Info: https://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___