XSF Discussion - 2020-05-24

https://xmpp.org/extensions/xep-0045.html#example-9 What about adding to the room features: <feature var='http://jabber.org/protocol/muc#admin'/> When user affiliation is "owner" or "admin", and <feature var='http://jabber.org/protocol/muc#owner'/> When user affiliation is "owner"?

xnamed^: what for exactly? Because this can change, so you would have to keep checking it

Or track your affiliation, in which case it's not needed anyway

so I have xep313 latest (mam:2) and 0.5 (mam:1) side by side open, what exactly caused the namespace bump? IIRC it was only a tiny thing, but the examples all look the same to me (besides s/mam:1/mam:2/) ✏

That stanza-id was required

ahh, § 3.5, not sure why we did a namespace bump for that, that appears to have been a mistake in hindsight

So that clients knew they could count on stanza ids being archive ids

right, but that could have been simply annouced via an extra feature, no? ✏

Dunno. Maybe.

flow, yes, could’ve been

+1, mistake in hindsight once that became the only change

Is there a quick way to emulate / write a module for a server that automatically returns an error for sasl? I'm trying to see which clients display the error text (and which don't)

Probably 3-4 lines in prosody

module:hook("...event...", function (event) return event.origin.send(st.stanza("failure", {xmlns=...}) end)

event can be figured out from https://prosody.im/doc/developers/events or mod_saslauth code

you really shoud think about that, lets just add a feature strategy

especially on experimental XEPs

because then we could argue, there is always only a :1 we never need :2 because we just do a <feature name="mam:2">

and this does work for all changes, not only for additional btw

you really should write down a guidline when to use features and when to use a namespace bump

and then people should honor it, if they like it or not

so its consistent

It works whenever the behaviour was allowed but not required by the previous spec. ✏

lovetox> and this does work for all changes, not only for additional btw I doubt that is true, there are certainly valid reasons for a version bump

a feature works for something thats a feature, hence OPTIONAL

but thats not the reason they are used lately

its, oh there is some sensible change that XEP needs, everybody needs that change, but there is some impl out there that does not want to upgrade, so lets make the required change OPTIONAL to not break some client

and i get this notion for a XEP that is in Draft or whatever final status there is

but not for Experimental

but anyway i can also parse 27 features before i know the server does what i want, it doesnt matter much

Hello guys, just a reminder to put your news into the upcoming XMPP Newsletter for this May if you have anything to say or already published! 📬 We draft the Newsletter on Github and will archive to the Wiki once released: https://github.com/xsf/xmpp.org/pull/706 Merge requests are welcome! 👋

emus: How we can edit a draft?

You should basically be able to create a merge request. If you don't want you can just comment a section. But merge request would be easier

Neustradamus_: pull requests on github are the quickest way emus: have you had a look at mine?

Ehm, I though I merged everything, or?

Okay, thats really odd and happened before - I don't get ANY email or notficiation about those pull requests (anyway thanks for you work!) ✏

Hi, how can one add @xml:lang support to XML Schema?

Do we have any such example?

Apparently I have to define xmlns:xml='http://www.w3.org/XML/1998/namespace', which goes against the XML spec AIUI.

wurstsalat - thanks, is merged

Indeed it does, xmllint rejects it.

emus, maybe you have to adjust notifications for your own fork?

will check, but thats weird acutally 🤨️

Re the Bookmarks thread, I remembered this exists: https://xmpp.org/extensions/xep-0194.html

wasn’t this intended for contacts?

Seems to be

Zash, not sure how you think this has anything to do with the thread

this tells your contacts that you joined a MUC

Why is that so different from telling your own clients?

Might be a subset of it? :/

Zash we already have a mechanism to tell our own clients

its called Bookmarks

:(

MattJ, as you said "track your affiliation" it's needed to let client know that to show actions for those features which can be accessed without having to join the MUC

Link Mauve> Hi, how can one add @xml:lang support to XML Schema? Isn't xml:lang implictly everywhere?

flow: I'd expect to be implicitly allowed everywhere since it's a namespaced attribute

Zash, yep, me too

What if there's a limited number of occurs, don't we need semantics to say "it's fine if there's a different @xml:lang"?

That seems more likely

What do you mean

flow, yes, but how do you make the schema aware that an element can be duplicated if the @xml:lang is different?

Can schema even express that?

I can’t find any hint that they do.

Zash, that was my comment as well, is it possible? :p