On 31.12.22 13:19, Dave Cridland wrote:
On Fri, 30 Dec 2022 at 19:40, Florian Schmaus <f...@geekplace.eu <mailto:f...@geekplace.eu>> wrote:On 30.12.22 11:05, Dave Cridland wrote: > On Thu, 22 Dec 2022 at 09:23, Matthew Wild <mwi...@gmail.com <mailto:mwi...@gmail.com> > <mailto:mwi...@gmail.com <mailto:mwi...@gmail.com>>> wrote: > On Wed, 21 Dec 2022, 15:05 Florian Schmaus, <f...@geekplace.eu <mailto:f...@geekplace.eu> > <mailto:f...@geekplace.eu <mailto:f...@geekplace.eu>>> wrote: > Zash's proposal is, as far as I understand it, just an > optimization > allowing a sending entity to determine if a stanza will hit the > limit or > not, without trying to actually send it. > > It is and it isn't. Right now, if a stanza is over the limit then > most implementations will close the connection with a stream error. > Not closing the connection is non-trivial for implementations if > they want to avoid DoS and use a standard parser. > > I think this is a good summary of why the <max-bytes/> is needed - it > allows a sending implementation to alter its behaviour for the better. > > I don't think there's the same justification for <idle-seconds/>, > though, is there? What would a sending implementation do? Uh, there is much value in the information found in <idle-seconds/>. Simply put, it allows the receiving side to delay liveness checks for the connection until it has been idle longer than idle-seconds.Really? So as a client, if a server says that connections can be idle for up to 1800s, you'd not bother checking them for a half hour?
I guess this is up to the implementation to decide.
I can see why the *server* might adapt its liveness checks to match the client's, but this XEP doesn't cover that.
I assume the XEP has also s2s connections in mind? Whereas I am mostly concerned about c2s connections, especially mobile ones.
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
