jdev - 2021-01-14

*facepalm* I just realized that even matching on the namespace of an IQ payload won't work because XEP-0077 uses a different namespace for the feature and for the IQ. I guess I just don't get to support this because my entire implementation makes assumptions that just aren't true and I'm way too far in now to change the API drastically

Re-reading the relavant sections of RFC 6120 it's not even clear ot me how IQs prior to the stream being negotiated should work. I assume you can't receive a response to an IQ across a stream restart, that seems like it would be bad and maybe the stuff about the session being reset implies that, but it does sound like you could send an IQ in the middle of eg. negotiating SASL, which also seems bad. SASL says it needs security layer byte precision, which prseumably means you can't interleave random IQs, but now we have to special case individual features.

Presumably you don't negotiate multiple things concurrently

Presumably, but as far as I can tell 6120 allows it because you can send IQs at any time just like after the session is started

eg. in IBR there doesn't seem to be any indication of when registration should be sent. Gajim just tries it immediatly after the first stream, but it looks like in theory you could do it at any time

Imagine a world where any resemblance of IQ stanzas are a pure coincidence.

Yah, that's what I'm trying to do now, but I'm worried that I've already gotten this API wrong once and will have to break it most likely, I'd like to understand fully what RFC 6120 means so that I don't end up having it be broken again when some other widely used legacy XEP turns out to do this in a slightly different way that I didn't account for

IIRC stream setup is supposed to be synchronous, which is why I would think that you can't mix negotiation things.

Then again, maybe I don't care. It's obviously a requirement that I support Bind which I know I can do without breaking this API, and I *think* it's a requirement that I support IBR since that's so widely used, but maybe if I don't know about anything else then it's not widely used enough for me to care

Get features → Pick one → complete or abort → restart stream (maybe) → go to 1

Yah, I do think the stream start *has* to be synchronous, whether the RFC says it is or not if I don't do that there will just be security implications that are worse than a tiny bit of incompatibility with a theoretical client somewhere

This is extremely frustrating. Maybe I'll write a procedural XEP that says "In a hypothetical future XMPP 2.0 routable elements probably won't be allowed before the stream is fully negotiated, so no future XEPs will be accepted that introduce new features that require IQs and the like"

Not that anyone is writing them anymore anyways, but just to see what board and council think and to make it "official" in some way

Another revision of the RFCs maybe

One day

Sam Whited, I’m fairly certain you can get full support for that

routable elements pre-bind are considered a terrible idea by everyone I have heard talking about that

I've heard that some libraries lack easy ways to implement new stream element level request-response handling.

Zash: I'd be curious to know which ones if you can think of any? Do they just hardcode the stream negotiation process with eg. StartTLS, SASL, then Bind and call it a day?

I sense smack

If that's what they do I have a hard time imagining that they *do* support routable elements pre bind (but not stream level handling)

But it would be good to know before making some sort of deprecation policy

It's Smack. I heard it from Ge0rG. /hides

the stream negotiation process in smack is a fucking nightmare.

you have threads running in parallel, sitting on semaphores that are triggered by message processing handlers.

Zash> I've heard that some libraries lack easy ways to implement new stream element level request-response handling. That's something I've implemented in Smack nearly 2 years ago

flow: with explicit request / response elements, and semantic support for embedding error elements?

last time I checked, it was possible to define my own stream elements rather easily, but not have a way to parse out a standard error element from them

because the error parser was bound to the three basic stanza types, IIRC

but either way I'm on a heavily diverged fork of 4.3.5

Thanks, I guess I should look into how smack works before writing anything

Although given that all (almost all?) new stream features are stream elements anyways I'm not sure that it matters either way, seems like if it wants new features it would have to fix any outstanding problems

Regardless of what the policy is

Probably not worth the effort to write a policy though now that I think about it. As far as I know it's widely agreed on like jonas’ said

Stream negotiation errors are unfortunately bound to their respective namespace (eg sasl errors), unless they're fatal enough to use stream errors.

Ge0rG, I would be great if you would add that the Smack version in question is old, outdated, and divereged, when you complain about Smack

Heh

API signature is at https://github.com/igniterealtime/Smack/blob/71f5cfe3dae9b20269bd174c04693610e7fcbcac/smack-core/src/main/java/org/jivesoftware/smack/AbstractXMPPConnection.java#L1402-L1404 ✏

The joys of software