On Sat, 31 Dec 2022 at 13:15, Florian Schmaus <f...@geekplace.eu> wrote:
> 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. > > Yes, though I wonder if this falls into the category of a little knowledge. > > 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. I suppose so, but the only case where this makes sense (to me, mind, and what would I know about S2S on flakey networks?) is where you have a bidi S2S session and both sides can adapt the liveness checks to be the minimum of either party, only that's what they'd be anyway in effect. But explicit > implicit. Also, if you have '198 in effect, do we care about idle anymore? Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
