jdev - 2021-01-20

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

(not the xmpp:version from XEP-0206, but the ver attribute from XEP-0124, to be clear)

It has '1.6' 🤷️

Urgh. If people are going to discuss BOSH can they at least put it in NSFW tags or something? :(

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

There is that spoiler message XEP...

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

Especially 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

*sigh* it would almost be easier to revive the websocket over HTTP/2 I-D than to continue implementing BOSH.

Swiften also sends 1.6, FWIW.

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

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

Sam Whited, revive what? doesn't https://tools.ietf.org/html/rfc8441 support it?

AFAICS, Swiften doesn't care at all about the ver, it just includes it at 1.6

I *suspect* that's true of every implementation, but have no evidence to support that.

Kev, Prosody seems to do the same ✏

Kev: 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)

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

I'll stick with 1.6 for compatibility then (why not). Thanks

I've implemented it once and a bit. I think another implementation is in my future, but I'm trying to avoid it.

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

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

Sam Whited: I was rather recently surprised by that RFC also :)

The next question is will the same thing work over http/3

Another 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)\

Dunno what libraries do, but Prosody tweaks the namespace on outgoing stanzas to have the proper jabber:client namespace if it's unset.

Users can send whatever arbitrary XML they want, so that's not an option

I feel like there would be type system things you could do here

But 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

Then 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

ideally users are not able to construct IQ instances without a namespace (for the IQ child element) ✏

I just realized that we are talking only about jabber:client / jabber:server as namespace

That may be a nice place to enforce that iq stanzas have an @id attribute as well, and other constraints

oh yah, sorry, wasn't thinking of the IQ child

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

in 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

So right now if you sent "iq" with no namespace those rules wouldn't trigger either

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

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

(Why couldn't we have a websockets-for-normal-clients that's just the same as the TCP binding but with WS framing?)

I wonder that every time I read through this spec…

I'm sure there was some sort of good reason for doing it this way, but I have no idea what it is.

It's because browsers don't have streaming XML parsers exposed to JavaScript

Thus every frame must be a vaid XML document.

oh yah, that makes sense

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

Heh, I still remember trying to convince Mike Shaver to add XMPP to Firefox at an OSCON in Portland around 2002/2003...

I guess technically some server could only expose that

But WebSockets have sub-protocol negotiation, it wouldn't be super hard to add another for those with streaming parsers

stpeter: as a javascript feature or as part of that chat product that was built in for a while? Either way, that would have been fun :)

You could have used it to get trough web stacks and firewalls, but now you could do that with ALPN instead.

> why would anything use websockets that's not actually the web? another easy firewall bypass Sam Whited

Oh yah, firewall bypass makes sense

There are desktop clients with BOSH support after all

Sam Whited: the idea that DizzyD and I had was that they could use XMPP for real-time notifications and experiences within the browser

you've got your network security people who refuse to expose anything to the internet that can't be "protected" by their enterprise (tm) WAF

nifty

(this was before xmlhttprequest and such)

stpeter, so you invented push notifications? :)

Oh, I though XHR dated back to the 90s, better recallibrate that.

Zash: not sure actually

Or maybe it's just so long ago that my brain is compressing the 90-00 era into one...

Well I'm wrong.

https://en.wikipedia.org/wiki/XMLHttpRequest#History

I always think of XML only really taking off in the early 2000's, not that I was paying much attention at the time so I'm probably wrong