XSF Discussion - 2023-05-17

Why was XEP-0353 (Jingle Message Initiation) namespace version downgraded in v0.6.0? There are new things (like <ringing>, use or the "store" hint) that were not presend in 0.3.1. I have to update my implementation, and normally namespace version is an indicator of that.

also the XEP talks about "media type" which comes from XEP-0167, but it's really useful with other non A/V calls use cases (like file transfer). Would be nice to make it more explicit.

goffi, as the extension is already deployed, it was decided that backwards-incompatible changes were not desirable

So the latest version should be compatible with the deployed version

I think it's not, the store hint and <ringing> element where not present.

Anyway I'm updating now

were not present*

that's right that this extension it's delicate at there is not discovery, so that would mean sending one <message> for each supported namespace.

So I kind of get why this has been done this way.

Store hint is in another namespace anyway. The addition of <ringing/> is indeed "technically" wrong, but it's optional and hopefully a lesser evil than entirely breaking compatibility with existing clients.

a store hint can be added without a namespace version bump, as its just a hint

I think it is for the question whether or not a namespace bump is required

Sure. New (non-editorial) XEP versions can change requirements without changing the protocol syntax, and only syntax changes require namespace changes.

I am sorry, "synatx" appears to be quite abstract in this discussion

Mandating a store hint though isn't the same thing as "just adding a store hint", right ✏

The question of bumping the namespace is always "does something break if we do not bump it"?

which is also quite abstract

<ringing/> seems to be mandated, but not by RFC keywords. I wonder if something would break if older impls under the same namespace wouldn't send it

I would hope not, but this seems to be borderline

but I am happy to see urn:xmpp:hints back in buisness \o/

What happens if thing on the new version talks to thing on the old version?

goffi, maybe you could help to answer this question: do you need to upgrade your implemention so that it follows the current spec or does something break if your implementation speaks to a newer-spec implementation?

flow: I have other issues in my implementation (the media type was missing notably), resulting in issues, so it was broken anyway in my case.

goffi, I see, thanks for sharing :)

Adding elements shouldn't require a namespace change, surely? Rather removing, renaming, or changing the semantics of existing ones should

As a general rule, I would think so, yeah.

Unless something really bad happens if the receiving entity ignores a new element.

> Adding elements shouldn't require a namespace change, surely? This is not clear. There is an argument for immutable namespaces, and some implementations may validate or otherwise depend on adherence to a known schema. That most implementations just look for and pluck out elements they are expecting is not necessarily a fundamental design choice of XMPP (ignoring unknown namespaces is, explicitly).

Historically, we haven't taken schemas _that_ seriously.

And practically, it'd be pretty painful for minor changes.

Yeah, but let's admit that this is mostly laziness and lack of nice tooling, rather than an explicit choice :)

Agree

and there have always been some projects doing stuff with schemas

I'm not against the addition of <ringing/>, to be clear. I think extending existing namespaces is something we shouldn't make a habit of, but sometimes the alternative options are simply worse.

Part of the problem is mismatch between XEP status and deployment status, I think. I.e. Experimental things getting implemented and deployed everywhere without advancing to Draft.

I think changing namespace is basically always bad, but sometimes necessary, since it destroys forward compatibility and makes back-compat take a bunch more code. Ref all my code that looks for one of three jingle namespaces and then treats the elements exactly the same no matter which of the three it finds...

"some implementations may validate or otherwise depend on adherence to a known schema" < This, yes.

xmpp-parsers checks strictly, unless specified like bookmark2's <extensions/>

fwiw this has helped uncover some bugs already in other implementations ✏

You should be able to check <extensions/> strictly, since it can contain no children in it's own namespace

True

IMO schemas are descriptive, especially pre-Final status for XEP. Doesn't mean not useful, but if a client barfs on an unknown tag being present instead of ignoring it, especially on non-Final namespace, that's asking for trouble

Relatedly, recently I was looking at mentions (372), and a proposed change for referencing something else than <body/> completly breaks this. That is, the possibility to add an "id" attribute on any other element to refer to it via the <reference/> tag

And I already live with the pain if namespaces that were changed too often (like the three identical jingle ones)

pep.: Sounds like an actual use case for namespaced attribute?

Well stuff like this is generally negociated.

For example in 463, I have introduced a namespaced attribute on <{muc}x/> in the reply from the server, but that's only if the client signals it knows the protocol ✏

But maybe that's a use-case for these yeah.. even not negociated

But then all hail breaks loose.. if anything can be added anywhere. Isn't it that extensible pieces are generally defined extensible preventively? Or negociated.

Well new namespace things can surely be added anywhere. And if implementing a pre-Final protocol one should expect it is perhaps not... final. IMO ✏

Except in some cases where the spec really says do not I guess, like if must have only one child no matter the namespace and data form value must have no element children of any kind

Unless negociated*

Anything is possible anyway when negociated

singpolyma, do you see a better alternative than bumping the jingle jingle namespace (three times)?

Hello all, FOSSY conference has put out their Call for Booths now as well: https://2023.fossy.us/call-for-booths/ While I can apply for an XMPP booth as a community project, I think it might be a more impactful application if it were an "XSF booth" such that it is both a community project and a non-profit org. So I'm wondering if it would be possible to do this? All I really need is someone on board to say "yes" I guess since I'm not asking anyone to do anything really, happy to provide materials and organize volunteers for the booth etc myself

flow: I would have to dive into why the namespace was bumped to be sure

I am also not sure why we should not be able to add unnamespaced attributes (and namespaced) elements later on without a namespace bump

under the assumption that those additional attributes/elements can be ignored

> Historically, we haven't taken schemas _that_ seriously. Just because the XEP schemas aren't great, doesn't mean that someone can't produce a schema from the normative text and validate on that. Because that sounds like the sort of thing people might be hypothetically doing.

fwiw, I take schemas seriously :)

I think people mix two aspects of schema validation: validating things the schema describes and validating things the schema does not describe

Hm, doesn't affect the holy commandment of "Ignore what thou doth not understandeth" ?

It does, because you understand the namespace, and what you received should not be in it.

(Whether you're doing schema validation or fuzzy `e.get(name, namespace)`

while IIRC XML schema's usually forbid extending the XML with attributes and elements not described by the schema, this is some limitation that we in XMPP should not follow, as it makes it impossible to extend an existing protocol without unnecessarily (from the protocols pov) namespace

I suppose there's also no reason a XEP can't define a new element in a new namepace and not change the namespace for existing elements

> I suppose there's also no reason a XEP can't define a new element in a new namepace and not change the namespace for existing elements Yes.

This is what we did in XEP-0313 not too long ago

Other places too.

that would be fine. I just dislike changing for existing elements when there is no breaking change to how they are used. new elements in new namespaces vs existing namespaces is the same either way to me