XSF Discussion - 2018-11-18

what the heck is the jabber:x:signed namespace?

https://xmpp.org/extensions/xep-0027.html oh-kay

so conversations does emit that on presences

That's how 27 works?!

I didn’t even know about '27 until I saw that huge jabber:x:signed blob on a presence stanza

jonas’: thank glob for PEP

Wasn’t it around the time of 0027 that PEP got invented?

Because it was clearly getting out of hand.

regarding xep198 'max': Smack throws away the session after min(max-client, max-server), to releaes resources because it assumes the session is no longer resumeable

mmm

I thought about that, but then I figured that the gain in resource consumption is most likely neglectible and giving the stream another chance might be worth it

(also, I imagine servers might keep the ack counter around longer than max and return it on failed resumption which is nice)

Yes

flow: Hmm, I guess I should no longer include the 'max' attribute with `<enabled/>`.

the @max isn’t used in aioxmpp at all, actually.

jonas’, right, the implementation is before xep198 had that ack counter

I cleary see why would try oportunistic resumption in any case

which leads to the question what the use case for 'max' actually is

if you requested zero, you can check whether you got it

if you ask why would anyone want that: https://github.com/horazont/aioxmpp/issues/114

Most likely the use case for the client 'max' is to limit the duration of the ghost presence

yes

But why check whether it worked?

Holger, dunno? :)

jonas’, I only had a quick look at #114, but doesn't the user simply want to disable resumption?

flow, yes

ahh wait, let me guess, the only way to disable resumption with <enable/> is max=0?

:)

actually, no

max=-1? ;)

resume='false', no?

> If the client wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false [5]. For information about resuming a previous session, see the Resumption section of this document. ✏

Right.

phew, I thought I remember that the attribute exists, but a quick look at the example didn't reveal it

in fact, aioxmpp makes resumption_timeout=0 and request_resumption=False equivalent

flow, you need to look at Example 8

the first one is for resumption-less SM

so ok, and I guess it is also sensible that the server announces a his 'max'

which means I may want to introduce a switch in smack to enable opportunistic resumption

because Holger does dirty things

Do you not want to resume anyway just to get the h count?

Even if the time has run up

daniel, it depends: if you want to minimize resource usage you may want to release the resources as soon as possible, if you want to get the 'h', then not. That is why I'm thinking about a switch to make the behavior configurable in Smack

flow: and then there is the situation where the client clock is running differently from the server clock

Is https://xmpp.org/registrar/formtypes.html missing muc#roominfo or am I looking in the wrong place?

you’re looking at an outdated page

most likely

... and why is there a menu at the top *and* at the bottom of https://xmpp.org/ ?

And how do you find the registry in this piece of marketing material?

you are at the right place for the registry

unfortunately, it’s not being maintained

:<

yes

https://github.com/xsf/registrar this is the source

Please use your own neural network to synthesize my reaction to this.

Anyways, the answer to my question is "no, there's no field for a web chat URL registered already"

And I'm not convinced there needs to be