Sam WhitedI'm sure I've asked this before and don't remember if I ever got an answer, but BOSH defines a version string during negotiation, but as far as I can tell there is no actual version listed anywhere. The XEP version doesn't even match the same format (and of course involves lots of changes that wouldn't change a protocol version anyways), so I have no idea what value to put there?
Sam Whited(not the xmpp:version from XEP-0206, but the ver attribute from XEP-0124, to be clear)
Zashlooks at Prosodys mod_bosh
ZashIt has '1.6' 🤷️
KevUrgh. If people are going to discuss BOSH can they at least put it in NSFW tags or something? :(
Sam Whitedhah, that would be a good April 1st XEP. NSFW feature (which could be a real feature) but also we list technologies such as BOSH that must be behind it.
ZashThere is that spoiler message XEP...
Sam WhitedZash: 1.6 appears to be used in one of the examples and is a version of the BOSH XEP itself, so maybe that was the intent? I have no idea.
Sam WhitedEspecially since the XEP version might be bumped just for typos and recent ones use major.minor.patch syntax which doesn't fit the bosh version syntax
Sam Whitedlooks at who introduced the new version syntax and broke things… *blushes*
Sam Whited*sigh* it would almost be easier to revive the websocket over HTTP/2 I-D than to continue implementing BOSH.
KevSwiften also sends 1.6, FWIW.
Zash1.6 was probably the latest version when mod_bosh was written, it was committed ~2 months after 1.7 was published (according to the xep changelog)
KevBut my view is that if you're implementing BOSH for anything less than a significant amount of money (or insert other motivator here), you're probably soft in the head.
moparisthebestSam Whited, revive what? doesn't https://tools.ietf.org/html/rfc8441 support it?
KevAFAICS, Swiften doesn't care at all about the ver, it just includes it at 1.6
KevI *suspect* that's true of every implementation, but have no evidence to support that.
ZashKev, Prosody doesn't seem to do the same
ZashKev, Prosody seems to do the same
Sam WhitedKev: you're not wrong… this is the second or third time I've tried to do this (only once for money, and even then only a moderate amount of money)
Sam WhitedAnd every single time I think "this time's the one, this time it will work correctly" and I always end up abandoning it in frustration.
Sam WhitedI'll stick with 1.6 for compatibility then (why not). Thanks
KevI've implemented it once and a bit. I think another implementation is in my future, but I'm trying to avoid it.
Sam Whitedmoparisthebest: thanks for the link, I thought this had never gotten beyond I-D for some reason. I'll have to re-read (assuming this is the same thing) and see. Maybe websockets actually does work on HTTP/2 now and I just have old info
Sam WhitedI guess I didn't abandon the commercial one in frustration, HipChat just ended up being sold and I left the company. No idea if they ever used it or not.
moparisthebestSam Whited: I was rather recently surprised by that RFC also :)
moparisthebestThe next question is will the same thing work over http/3
Sam WhitedAnother stupid question which I just realized is a problem (potentially): what do people do in their libraries if someone tries to send an IQ without a namespace? Normally it would just be in the default namespace and therefore still a stanza, but if I implemented the websocket subprotocol as discussed earlier it wouldn't have a namespace and wouldn't be a stanza. Maybe I should detect anything called "iq", "message", or "presence" without a namespace set and just set it to the right thing (although technically I guess that's wrong and you could have a non-stanza thing called "iq", but that would be dumb so I'm not sure if I care)\
Zash Dunno what libraries do, but Prosody tweaks the namespace on outgoing stanzas to have the proper jabber:client namespace if it's unset.
flowideally users are not able to construct IQ instances without a namespace
Sam WhitedUsers can send whatever arbitrary XML they want, so that's not an option
ZashI feel like there would be type system things you could do here
Sam WhitedBut that's a good point, maybe if it's sent with the IQ struct I could find a way to make those always get the right namespace set at least
Sam WhitedThen if users deliberately encode XML tokens that include "<iq xmlns=''/>" that's fine, it's their problem, but if they use the safer library features they get the correct behavior
flowideally users are not able to construct IQ instances without a namespace (for the IQ child element)
flowI just realized that we are talking only about jabber:client / jabber:server as namespace
ZashThat may be a nice place to enforce that iq stanzas have an @id attribute as well, and other constraints
Sam Whitedoh yah, sorry, wasn't thinking of the IQ child
Sam WhitedI have ID enforced at the stream level actually. It looks at all tokens passing through and if any of them are "iq", "message", or "presence" with namespace "jabber:client" or "jabber:server" it adds IDs (and "from" if it's an s2s connection)
flowin Smack, stanzas implicitly have the right namespace (jabber:client in smack's case), and when the stanza is serialized, Smack will try to avoid printing the namespace declaration if it is redundant
Sam WhitedSo right now if you sent "iq" with no namespace those rules wouldn't trigger either
Sam Whitedmeh, maybe I'll just add the namespace to anything called "iq" with an empty namespace in the same place IDs are enforced. It's just easier and if it ever causes an actual problem I'll eat my hat
ZashSimilar in Prosody, missing xmlns attribute normally means it's the same as the parent, or the default stream namespace, but websocket being a bit special there means special care needs to be taken somewhere in the pipeline.
Zash(Why couldn't we have a websockets-for-normal-clients that's just the same as the TCP binding but with WS framing?)
Sam WhitedI wonder that every time I read through this spec…
Sam WhitedI'm sure there was some sort of good reason for doing it this way, but I have no idea what it is.
ZashThus every frame must be a vaid XML document.
Sam Whitedoh yah, that makes sense
Sam WhitedActual other question: I was just thinking I'd do the client side because "why not?" (once I've done the receiving side it's pretty trivial to make the handshake work for a client connection too), but why would anything use websockets that's not actually the web?
stpeterHeh, I still remember trying to convince Mike Shaver to add XMPP to Firefox at an OSCON in Portland around 2002/2003...
Sam WhitedI guess technically some server could only expose that
ZashBut WebSockets have sub-protocol negotiation, it wouldn't be super hard to add another for those with streaming parsers
ZashYou could have used it to get trough web stacks and firewalls, but now you could do that with ALPN instead.
moparisthebest> why would anything use websockets that's not actually the web?
another easy firewall bypass Sam Whited
Sam WhitedOh yah, firewall bypass makes sense
ZashThere are desktop clients with BOSH support after all
stpeterSam Whited: the idea that DizzyD and I had was that they could use XMPP for real-time notifications and experiences within the browser
moparisthebestyou've got your network security people who refuse to expose anything to the internet that can't be "protected" by their enterprise (tm) WAF
stpeter(this was before xmlhttprequest and such)
moparisthebeststpeter, so you invented push notifications? :)
ZashOh, I though XHR dated back to the 90s, better recallibrate that.
stpeterZash: not sure actually
ZashOr maybe it's just so long ago that my brain is compressing the 90-00 era into one...