Re: [Standards] Call for Experience: XEP-0198: Stream Management

[Andrew Nenakhov]

чт, 20 февр. 2020 г. в 16:05, JC Brand :
> > Through the message archive and with our device sync protocol.
> What if you had only one device and presence stanzas were sent during
> the disconnection?
>
> With your way of doing things, you'd have to query MAM every time you
> load a web-page that contains an XMPP chat. Seems excessive.
>
> I know your web chat client isn't meant to be embedded in websites where
> people navigate around, but that is a common use-case.

Well. This requires an explanation of how we see things. What is, exactly,
a use-case for stream management? It helps in situations, when a connection
is lost frequently, yet, briefly. Where can this occur? On a desktop, with
a stable connection, it is hardly a problem: connections are stable there,
and if something happens, one full reconnect every 30 minutes (much more
rare in practice) is something any client can tolerate. This leaves us with
mobile devices and browsers.

Mobile clients are, currently, a valid use-case for stream management.
Mobile devices often hop from wifi to cellular connection and back, are
brought to places with bad signal coverage, so they can benefit from SM.
However, only on one platform - Android. iOS devices would not benefit from
stream management at all - they can't maintain connection in the
background, and rely on APNS to receive notifications about a necessity to
connect to server. Android seems to be on the same trajectory: persistent
processes have more and more difficulties living in the background with
each release. Some manufacturers even make it even worse, see
https://dontkillmyapp.com/

I believe that writing is on the wall for mobile devices, and in the long
term we are destined to be forced to use push notifications in the future.
So, only browsers remain.

If a browser is emulating a full-on desktop app, like Xabber for Web, it
does not really need SM, just as desktop apps don't need it. If it behaves
like converse.js, reloading on every page... well... it's a reasonable
place to use SM. I personally can't really imagine a scenario where a user
might want to have a real XMPP experience that way, complete with roster
and presences, but I trust you that you know your users better.

(I can very well imagine a scenario where an XMPP is used on a website to
provide an olark/purechat/livechat chat widget to talk to site owners, and
in fact we're making a rather nice chat widget ourselves
, powered by our awesome group chat
protocol, we break it from time to time and do not always answer to
incoming requests, so I don't promise stability just yet)

So. Back to SM. Long term, we're dealing with 2 types of clients: one that
have a stable connection, and ones that connect to servers infrequently and
do not maintain a connection at all. The latter type of clients relies on
message archive and our device sync protocol, and I can't call fetching
messages from an archive as some excess, and practice shows it works quite
well. (btw, we're disabling offline messages)

What other problems we have with reconnection? Roster and presences. Roster
is mostly not a problem thanks to roster versioning. Presences. It's a big
problem I'm still on the fence for this one. Receiving all presence
information on each reconnect is not the ideal solution. I'm thinking of
using a presence versioning, akin to roster versioning, or maybe to
eschewing presences at all. The idea of 'always on' messaging has some
merit to it with always connected modern mobile devices, however,
personally, I am not ready to give up on green light bulbs on contacts just
yet.



-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[JC Brand]

On 20.02.20 11:37, Andrew Nenakhov wrote:

чт, 20 февр. 2020 г. в 15:33, JC Brand :

For what it's worth, our iOS and web versions work perfectly fine
without XEP-0198. Android version will have it removed, too. Restoring
a state > resumption of a stream.

How are you able to receive stanzas that were sent to you during the
short period that you were disconnected?

Through the message archive and with our device sync protocol.
What if you had only one device and presence stanzas were sent during 
the disconnection?


With your way of doing things, you'd have to query MAM every time you 
load a web-page that contains an XMPP chat. Seems excessive.


I know your web chat client isn't meant to be embedded in websites where 
people navigate around, but that is a common use-case.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[JC Brand]

On 20.02.20 11:49, Florian Schmaus wrote:

On 20.02.20 11:24, JC Brand wrote:

On 13.02.20 21:13, Florian Schmaus wrote:

On 2/11/20 4:21 PM, Jonas Schäfer (XSF Editor) wrote:

The XEP Editor would like to Call for Experience with XEP-0198 before
presenting it to the Council for advancing it to Final status.

With the advent of WebSockets and QUIC around the corner, we shouldn't
miss the opportunity to allow stream resumption over different
transports (TCP, BOSH, WebSocket, QUIC, …).

Stream resumption over BOSH doesn't make sense since it already has it's
own session management tokens (SID and RID).

Quite contrary, even tough BOSH has a SM like mechanism built-in, I
think SM-for-BOSH is useful if you want to resume a stream previously
established via different transport, e.g. WebSocket or RFC6120-like TCP.


BOSH has it's own timeout independent from SM, so I can imagine that
causing issues when trying to switch from BOSH to some other transport.

In a web-client, you'll run into problems even if you don't switch
transports. When you're using BOSH and then reload the page (and
reconnect with BOSH), your reconnecting to a still-running BOSH session,
there's nothing to resume SM-wise and trying to do so simply confuses
the XMPP server.

I remember lots of errors occurring server-side when I (mistakenly)
enabled SM for a BOSH connection.

These issues could probably be addressed server-side, but to day I'm not
aware of any servers that support SM over BOSH.

So, lots of extra complexity for what's IMO an edge case.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[Florian Schmaus]

On 20.02.20 11:24, JC Brand wrote:
> 
> On 13.02.20 21:13, Florian Schmaus wrote:
>> On 2/11/20 4:21 PM, Jonas Schäfer (XSF Editor) wrote:
>>> The XEP Editor would like to Call for Experience with XEP-0198 before
>>> presenting it to the Council for advancing it to Final status.
>> With the advent of WebSockets and QUIC around the corner, we shouldn't
>> miss the opportunity to allow stream resumption over different
>> transports (TCP, BOSH, WebSocket, QUIC, …).
> 
> Stream resumption over BOSH doesn't make sense since it already has it's
> own session management tokens (SID and RID).

Quite contrary, even tough BOSH has a SM like mechanism built-in, I
think SM-for-BOSH is useful if you want to resume a stream previously
established via different transport, e.g. WebSocket or RFC6120-like TCP.

- Florian



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

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[Andrew Nenakhov]

чт, 20 февр. 2020 г. в 15:33, JC Brand :
> > For what it's worth, our iOS and web versions work perfectly fine
> > without XEP-0198. Android version will have it removed, too. Restoring
> > a state > resumption of a stream.
> How are you able to receive stanzas that were sent to you during the
> short period that you were disconnected?

Through the message archive and with our device sync protocol.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[JC Brand]

On 11.02.20 16:21, Jonas Schäfer (XSF Editor) wrote:

The XEP Editor would like to Call for Experience with XEP-0198 before
presenting it to the Council for advancing it to Final status.


During the Call for Experience, please answer the following questions:

1. What software has XEP-0198 implemented? Please note that the
protocol must be implemented in at least two separate codebases (at
least one of which must be free or open-source software) in order to
advance from Draft to Final.


Converse.js (MPLv2) supports XEP-0198 over websocket connections.


2. Have developers experienced any problems with the protocol as
defined in XEP-0198? If so, please describe the problems and, if
possible, suggested solutions.
Like others, I've encountered counter bugs. Unsure whether anything can 
be done in the XEP about this.

3. Is the text of XEP-0198 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
Have developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

AFAICT yes.

If you have any comments about advancing XEP-0198 from Draft to Final,
please provide them by the close of business on 2020-02-25. After the
Call for Experience, this XEP might undergo revisions to address
feedback received, after which it will be presented to the XMPP
Council for voting to a status of Final.


No.


You can review the specification here:

https://xmpp.org/extensions/xep-0198.html

Please send all feedback to the standards@xmpp.org discussion list.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[JC Brand]

On 14.02.20 11:06, Andrew Nenakhov wrote:

пт, 14 февр. 2020 г. в 14:03, Dave Cridland :

With the advent of WebSockets and QUIC around the corner, we shouldn't
miss the opportunity to allow stream resumption over different
transports (TCP, BOSH, WebSocket, QUIC, …).

I think people do that already. I vaguely remember a conversation where I 
suggested that '198 wasn't useful on BOSH, and got told that it was used for 
BOSH->WebSocket transitioning (since apparently the startup is then faster and 
more reliable).

For what it's worth, our iOS and web versions work perfectly fine
without XEP-0198. Android version will have it removed, too. Restoring
a state > resumption of a stream.
How are you able to receive stanzas that were sent to you during the 
short period that you were disconnected?



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[JC Brand]

On 13.02.20 21:13, Florian Schmaus wrote:

On 2/11/20 4:21 PM, Jonas Schäfer (XSF Editor) wrote:

The XEP Editor would like to Call for Experience with XEP-0198 before
presenting it to the Council for advancing it to Final status.

With the advent of WebSockets and QUIC around the corner, we shouldn't
miss the opportunity to allow stream resumption over different
transports (TCP, BOSH, WebSocket, QUIC, …).


Stream resumption over BOSH doesn't make sense since it already has it's 
own session management tokens (SID and RID).



XEP-0198 works well over Websocket. Converse.js has support for that.

JC



I am not sure if this is actually feedback for xep198, as "Stream
Management for QUIC" could be simply another XEP. But maybe xep198 could
at least mention that it is not strictly limited to RFC6120-like TCP
transport bindings, while stream management for other transports are
outside the scope of xep198 and instead specified in their own XEP?



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___