jdev - 2021-10-18

Zash, don’t we “just” need a stream feature for that?

<stream:features>[…]<i-do-support-XML-namespaces-properly xmlns='urn:xmpp:tmp:yeah-really'/></stream:features>

Then the client can do all the optimisations it wants.

What, negotiation in the application layer? Can't have that, it must be a .. DNS record? TLS extension? JSON file at a special HTTPS location?! /s

:D

isn't support of XML namespaces simply required in XMPP? I know there is the discussion around namespaces attributes, but those are either used or not

flow, last time I checked at least ejabberd broke when I declared the stream management namespace on the stream header

flow, last time we had this discussion, people mentioned implementations which (used to?) didn’t support them properly.

(and then attempted to use it)

I also saw scary parent.getChild('child') calls in many popular clients, meaning namespaces aren’t checked properly.

Depending on what `getChild` does, mind. In M-Link that’s a shorthand for `parent.getChild(‘child’, parent.getNamespace())`

That’s nicer than parent.getChild('child', ns::DONT_CARE). ;_;

Some would say Explicit > Implicit

Zash: I agree - it’s better to explicitly say “I want a different namespace from the parent”, rather than it being implicit in a small change in an always-passed string ;)

Link Mauve, don't look at what util/stanza.lua does.

it will make your head hurt.

jonas’, I see. Would be great if we could improve the situation. did you create an issue report?

It should be doing the same `parent.getChild(‘child’, parent.getNamespace())` thing

flow, I don't recall, it's been a while :)

Zash, there are some nasty corner cases around xmlns=nil in prosody.

True

re-implementing that is one of the reasons stanza.rs is more terrible than it would have to be ;).

Wasn't that because of the concept of a "default namespace", which differs depending on c2s vs s2s etc?

In XMPP we always need either the same ns as the parent, or an explicit namespace, so I’m happy with what we’ve got.

Zash, yep.

I think some token which is not a valid nsuri to represent that, instead of nil, would be great.

Perhaps