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

[JC Brand]

On 26.02.20 12:25, Andrew Nenakhov wrote:

пт, 21 февр. 2020 г. в 14:33, JC Brand :

I have worked on deployments where Converse.js is integrated together with 
roster and presences and/or MUC presences and where pages are regularly 
reloaded (i.e. not a single-page app).

Btw, I assume you use a strophe.js library. Personally, I didn't dive
into details, but my web developers who work with  web version of
Xabber, which also uses this library currenlty, complained to me about
SM implementation there. It was something about it counting stanzas
differently than ejabberd does. It was over a year ago so I am not
very sharp on details, but I can ask them for a clarification, email
me directly pls if you want it.


Converse uses Strophe.js but doesn't use any Strophe plugins (which 
includes SM).


Converse has its own independent SM module.

BTW, I know that someone from Jitsi was working on the Strophe SM plugin 
recently.



-JC

___
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]

пт, 21 февр. 2020 г. в 14:33, JC Brand :
> I have worked on deployments where Converse.js is integrated together with 
> roster and presences and/or MUC presences and where pages are regularly 
> reloaded (i.e. not a single-page app).

Btw, I assume you use a strophe.js library. Personally, I didn't dive
into details, but my web developers who work with  web version of
Xabber, which also uses this library currenlty, complained to me about
SM implementation there. It was something about it counting stanzas
differently than ejabberd does. It was over a year ago so I am not
very sharp on details, but I can ask them for a clarification, email
me directly pls if you want it.

> Is there anything specific about SM that you don't like?
>
> It's more lightweight than having to do MAM requests for all open chats as 
> well as making a new roster request every time your connection drops and it 
> also solves the problem of presences being dropped.

Things I don't like in SM is that it was often marketed as a way to
reliably control the message delivery in the past. Thankfully, now
it's commonly accepted that it's not its goal. But currenlty I find
this method of maintaining connection not viable for our most
problematic platform, iOS. Thus, versioned methods of resuming chat
state were born, and they're as applicable on desktops, as they are in
web / iOS / Android devices. In worst-case scenarios, these methods
result in equal amount of traffic as with SM on reconnection, in best
cases they result in smaller amounts of traffic.

Mind you, I'm not advocating to drop SM, it's just our position that
it is redundant for us.



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

[Andrew Nenakhov]

сб, 22 февр. 2020 г. в 14:49, Jonas Schäfer :
> Instead of dropping SM and introducing explicit versioning protocols
> everywhere, wouldn’t it make more sense to increase SM timeouts to something
> useful for mobile clients?

Versioned protocols have one more crucial advantage, that comes as a
natural side-effect: if we go for the restoration of state instead of
resuming the stream, we can cold-start a client way faster. You enter
your credentials into a client, boom, in 3 seconds you see all your
recent conversations, with marked unread messages, etc. Extremely
useful on web clients.

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

[Andrew Nenakhov]

To now overcrowd the discussion, I'll answer severals email in this one.

пт, 21 февр. 2020 г. в 13:25, Daniel Gultsch :
> Only someone who hasn't been on a German high speed train can say with 
> confidence that desktop and web clients don't need stream management.

This clearly looks like a first world problem. There is no internet
access in russian trains, at all. And, for that matter, there are no
speed trains either, but one between Moscow and Saint-Petersburg.

пт, 21 февр. 2020 г. в 13:37, Guus der Kinderen :
> You've clearly never experienced my parent's WiFi.

Sheesh just fix it! Buy them a decent router!!! They are like $30 now.
Why do you let your parents suffer a horrible WiFi?!


Jokes aside, I understand that sometimes desktops DO have bad internet
access, but it's rather an exception, than a rule. Anyway, in our
experience our approach works equally well (or better) than SM.

пт, 21 февр. 2020 г. в 13:39, Martin :
> Yes, mobile ≠ Android/iOS! Many notebook computers are connected
> to Wifi or "mobile internet" and used in public transport,
> (over-) crowded places, or rural areas with flaky connections.

One of the problems of XMPP as a whole is their targeting only small
subset of clients by some proposed extensions, and calling it a day,
despite obvious problems on other clients in different environments.
Proper approach is to target the most difficult plaftorm to work with
(in our world, it's iOS), and spread up from there. Current SM is ...
NOT really suitable for iOS. Thus, we're working out something else.
If Stream Management works for you, well, I don't oppose you using it,
but we seem to be on a better solution without it. Yes, our approach
is harder on the server, but I firmly believe that in 2020 the heavy
lifting shold be done by servers.



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

[Jonas Schäfer]

On Donnerstag, 20. Februar 2020 20:57:48 CET Andrew Nenakhov wrote:
> 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.

Interestingly, stream management can be thought of as a kind of presence, 
message and even IQ "versioning". If we think of stanzas as transferral of 
state, the initial state before the stream was established + the counters 
define the state at resumption on both sides.

The re-transmission of lost stanzas during resumption is catching up on lost 
state.

Instead of dropping SM and introducing explicit versioning protocols 
everywhere, wouldn’t it make more sense to increase SM timeouts to something 
useful for mobile clients? 

That leaves the problem that a server may not want to hold an indefinitely 
growing stanza queue for a client for a long time. To make this less 
expensive, we could define a sloppy fallback version of SM which the server is 
allowed to degrade to once it lost its patience with the client. That sloppy 
version could have relaxed requirements compared to normal SM or even normal 
XMPP streams, but in a way which isn’t hurtful (i.e. delivers an experience 
similar to a full reconnect, but potentially faster and with less traffic). 
For example:

- Deduplicate presence stanzas
- Relax stanza ordering requirements between presences and message stanzas, so 
that message stanzas can be replayed from an archive on resumption
- Reply to IQ requests as well as XEP-0409 directly-addressed (ephemeral) 
messages with an error once the sloppy period starts

Much of this sounds familiar to thoughts I think MattJ had about per-device 
offline messages, just plus some defined handling of offline sessions and 
presence replay.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
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 20:57, Andrew Nenakhov wrote:
чт, 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 have worked on deployments where Converse.js is integrated together 
with roster and presences and/or MUC presences and where pages are 
regularly reloaded (i.e. not a single-page app).


Other people have integrated it into Diaspora and other FOSS social 
networking sites, many which aren't single-page apps and therefore cause 
page reloads when people navigate around.


The site I'm working on currently will eventually want DMs and the 
ability to request a DM (aka presence) and it's also not a full SPA.



(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)


As Daniel and Guus have pointed out, you're not dealing with only these 
two types of clients. You can also have laptops connected to spotty wifi.



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.


Is there anything specific about SM that you don't like?

It's more lightweight than having to do MAM requests for all open chats 
as well as making a new roster request every time your connection drops 
and it also solves the problem of presences being dropped.




___
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

[Daniel Gultsch]

Am Di., 11. Feb. 2020 um 15:21 Uhr schrieb Jonas Schäfer :
>
> 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.

I have implemented Stream Management in Conversations. The
implementation is independent of other implementations. It is licensed
under GPLv3

I think we currently have very little experience for implementing this
on s2s; but with MIX upcoming, I understand that this is something we
eventually want to do?

So maybe we should hold back until we have experience for s2s as well?

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

Yes. My implementation (and I believe other as well) have suffered
from counting errors that are easy to make and hard to spot.

At some point we introduced the "streams should be terminated" if a
remote (that means server?) detects a higher than expected stanza
count. I’m actually not sure if server implementations implement that.

Maybe that should be extended to clients as well? Conversations on the
client side will just output a warning that nobody would ever see.


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

I noticed that the first section doesn’t mention  as a ping
methods; which I believe is a pretty widespread form of pinging.

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

Yes the TLDR from what I said earlier:
* No s2s experience
* Should all entities be more strict about closing the stream on
counting errors?
* Doesn’t mention  for pinging (Should maybe actually discourage 199 pings)


cheers
Daniel
___
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

[Martin]

On 2020-02-21 09:23, Daniel Gultsch wrote:
> Only someone who hasn't been on a German high speed train can say with
> confidence that desktop and web clients don't need stream management.

Yes, mobile ≠ Android/iOS! Many notebook computers are connected
to Wifi or "mobile internet" and used in public transport,
(over-) crowded places, or rural areas with flaky connections.
___
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

[Guus der Kinderen]

You've clearly never experienced my parent's WiFi.

Op vr 21 feb. 2020 09:25 schreef Daniel Gultsch :

> Only someone who hasn't been on a German high speed train can say with
> confidence that desktop and web clients don't need stream management.
> ___
> 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

[Daniel Gultsch]

Only someone who hasn't been on a German high speed train can say with
confidence that desktop and web clients don't need stream management.
___
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 г. в 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
___

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

[Andrew Nenakhov]

пт, 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.

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

[Florian Schmaus]

On 14.02.20 10:13, Georg Lukas wrote:
> * Florian Schmaus  [2020-02-13 21:14]:
>> 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, …).
> 
> Indeed, this is one historical quirk of 0198 that needs to be fixed,
> specifically the `location` element in
> https://xmpp.org/extensions/xep-0198.html#enable
> 
> There even was a short thread about this element back in 2017:
> https://mail.jabber.org/pipermail/standards/2017-December/034065.html

Thanks for the pointer. :)

> However, I don't see a way to address this problem without bumping 0198.

I do (in case you are talking about a namespace bump): Compatible
clients would just tell their service which transport bindings they
support and the service responds with the per-transport location
information.

Also note that clients may choose to simply omit this information if
they are fine with performing an opportunistic resumption which
potentially fails.

- 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

[Georg Lukas]

* Florian Schmaus  [2020-02-13 21:14]:
> 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, …).

Indeed, this is one historical quirk of 0198 that needs to be fixed,
specifically the `location` element in
https://xmpp.org/extensions/xep-0198.html#enable

There even was a short thread about this element back in 2017:
https://mail.jabber.org/pipermail/standards/2017-December/034065.html

However, I don't see a way to address this problem without bumping 0198.


Georg


signature.asc
Description: PGP 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

[Dave Cridland]

On Tue, 11 Feb 2020 at 15:21, Jonas Schäfer  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.
>
>
I believe that the implementation in Openfire (Apache-licensed, by
Jonny Heavey and Guus with broken bits by me) is complete.

I have implemented non-resuming variants in a number of places, these are
less interesting but perfectly functional.


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

The hard bits turn out to be simple, and the simple bits turn out to be
very hard indeed.

The hard bits are things like resumption, which is usually simpler than
expected even in existing architectures. The simple bits include counting,
which one would think would be trivial but always seems beset by
"interesting" edge cases in older software.

I have used a "debug mode" at times which injects additional stanza-level
attributes with the counters in; nothing that can be standardized easily
but really helpful.


> 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.
>
>
I have noted elsewhere that there exist implementations which deliberately
resume sessions on a different transport to that used to establish them;
this is not covered explicitly by the specification. It is unclear whether
it needs to be.


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

[Dave Cridland]

On Thu, 13 Feb 2020 at 20:14, 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, …).
>
>
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).


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


Likewise with QUIC, I imagine.

I don't know what we'd need to do in terms of explicit support - the tricky
part seems to me to be resumption across a cluster, rather than resumption
between transports.

Dave.
___
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

[Jonas Schäfer]

13 Feb 2020 9:14:26 pm Florian Schmaus :

> 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, …).
>
> 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?

I think indeed that such an extension is possible in a separate document (and 
out of scope for '198). Indeed, aside from the resumption target, xep198 is 
fairly transport agnostic. Adding new resumption targets to SM-over-TCP would 
also be possible from a separate document (e.g. via stream feature + attribute 
on  as negotiation).
___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>


--
Jonas Schäfer
This was sent from mobile, and I'm not good with those. Sorry for brevity and 
such.

___
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 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, …).

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?

- Florian
___
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

[Ruslan Marchenko]

Am Dienstag, den 11.02.2020, 15:21 + schrieb Jonas Schäfer:
> 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.
> 
Implemented in DJabberd::Plugin::SMX (GPLv1/Artistic) [1] plugin from
scratch independently.

> 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.
> 
No

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

Qoute:
If the former stream is resumed and the server still has the stream for
the previously-identified session open at this time, the server SHOULD 
send a 'conflict' stream error and close that stream.
EndQuote

On a first reading _that stream_ rendered in my mind as resuming stream
(not active stream). I think it needs to be rephrased to say that
clearly - which one should be kept and which terminated.

Also worth explicitly saying that only routable stanzas as defined in
rfc6120 must be counted. It is mentioned in intro however rather to
stress the point the SM nonzas themselves should not be counted, not to
define the full applicable scope.

[1] - https://github.com/rufferson/DJabberd-Plugin-SMX

___
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

[Jonas Schäfer]

On Dienstag, 11. Februar 2020 16:21:02 CET Jonas Schäfer 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?

aioxmpp (LGPLv3+) has an implementation [1], which I did from scratch when 
building the library (twice). It is, to my knowledge, independent of all the 
other implementations out there.

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

We’ve seen several times that people get the counters wrong. It turns out that 
it is harder than you’d think to find the right place to count stanzas and 
what even counts as a stanza.

I’m not sure what we can do there specification-wise. It is all there, but it 
still seems hard to get right on the first attempt. Maybe some pseudo-code 
would do? I don’t know.

> 3. Is the text of XEP-0198 clear and unambiguous? 

I think so.

> Are more examples needed? 

I don’t think so. As mentioned above, some cases around counter handling may 
benefit from pseudo-code, though I’m not sure if such code can be written in a 
way which is useful for different software architectures.

> Is the conformance language (MAY/SHOULD/MUST) appropriate?

Yes.

> Have developers found the text confusing at all? 

AFAIK not confusing.

> 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.
> 
> 
> You can review the specification here:
> 
> https://xmpp.org/extensions/xep-0198.html
> 
> Please send all feedback to the standards@xmpp.org discussion list.

EOF.

   [1]: https://github.com/horazont/aioxmpp/blob/
9d93b63b12f39478cfab1c46f09d274230ccf081/aioxmpp/stream.py#L2090

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[XSF Editor]

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.

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.

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.

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.


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
___