XSF Discussion - 2019-11-25

for this month, yes: https://wiki.xmpp.org/web/XMPP_Newsletter

nyco, thanks!

Alex, have you updated the mailing list memberships already?

jonas’: no, I don't have the keys to them, requesting some help there

cc @ MattJ, Kev ^

Alex: If you mail me what mailing list changes you'd like done, I can update lists.

To my Isode address please.

ha fun

I'm on a train at the moment.

It is not conducive to such things.

dwd just now sent the mail I wanted to send, but without taking into account that the mailing lists aren’t updated yet

https://logs.xmpp.org/xsf/2019-11-21?p=h#2019-11-21-142285cb0e1824d2 tho

Thanks Kev, will mail you shortly, still in some meetings

Kev: sent

Memberbot is online for the Q4-2019 membership applications

finally an easy election

there you go, first set of votes

👍

> The <text/> element [ in an <error> ] is OPTIONAL. [...] It SHOULD NOT be used as the error message presented to a human user This doesn't match current practice, and what else would you show users?

huh.

ah well, normally you’d know via the protocol what an error condition means and you should show that primarily

e.g. "MUC creation failed due to lack of permissions" for a <forbidden/>

and then you’d attach to that the <text/> from the peer I guess... in a "details" field

(without that use, the i18n of the <text/> does make zero sense at all)

of course you *could* do that

but why should you? if the server already has a more detailed error message

I believe I've mentioned a wish for a reusable set of text strings for the various stanza errors

with translations

and of course there is not exactly one error condition per server error

Personally I feel when I'm writing server code that I have a pretty good idea what text should be shown to the user when emitting an error (and it varies even within the same condition)

I think the error text sent by the server should detail the "why", while the error text generated from the condition and the action should be the "what plus basic why"

We could make custom "application specific" conditions for each instance of error, but the client would need to understand those and get some text from somewhere

in the example above, the server could say something like "Only users from domain X are allowed to create rooms"

Previously clients have literally copy/pasted the error description text from each condition in the RFC and displayed that

s/-/ / + title case gets you ... something

yeah seems all really a workaround for not giving server developers the responsibility to formulate a basic englisch sentence

lovetox, plus all other languages.

yeah and every client has thousands of strings to translate :)

Hence why I think it would be nice to have some basic common strings and their translations

Zash, agreed

how would something like that look

To add to the previous discussion on our voting system, I knew something was off with the membership one as well. I can't vote blank :)

lovetox, a huge .po file

Pretty much

Some file(s) in some format with forbidden = Forbidden | Förbjudet | VERBOTEN | no u

etc

Probably with some variants for eg conflict in MUC meaning something slightly different from conflict in IBR or in resource binding

pep., I agree that the voting could use some fixing. I’d go with some Schulze-like method (as suggested by flow) for council/board and add a way to abstain for member votes maybe. pep. would you shepherd this to get it into the Q1 membership meeting?

Zash, i have a hard time picturing this

you want a mapping of error conditions to texts?

with context

Pretty much

and how are you then going to use that po file

picking out the lines you need?

or importing the full po file, even though there are many strings in it you never use

jonas’, not in a state to answer (I'm a walking zombie, tired), but that's a secondary items I wanted to tackle yeah

That'd be up to you.

(though importing the whole file is probably easier to maintain)

And how do you know you'll never use some strings? These are things remote entities can send.

I'm no expert on .po file management and I don't wanna focus on specific formats.

Is there anything that says stream errors must only be sent in one direction?

https://xmpp.org/extensions/xep-0178.html#s2s says to just close the TCP connection if the cert is unacceptable