KevHandling of unhandled stanzas to a local domain. 6120 says " either (a) handle the
stanza as appropriate for the stanza kind or (b) return an error
stanza to the sender.". 6121 helpfully says just to do what 6120 says. This is clearly vague, as returning an error for every stanza that isn't handled must be wrong (e.g. bouncing a bounce).
KevWhat do people generally do - drop everything except iq get/set, which error? Error everything that could be errorred (including headline etc.)?
GuusKev Openfire delivers messages to the local domain JID to all configured admins.
Guuspresence stanzas appear to be treated as if the 'to' attribute was empty.
Guus(I'm looking at behavior, not code, so I might be missing things)
Ge0rGThere is also this weird duality where on c2s connections a client is sending to the account by default, not to the server domain
KevGe0rG: Weird duality?
Guusfwiw, the Openfire behavior likely predates 6120.
Ge0rGKev: well, technically your stream is to your account, so the default @to is your bare JID, it's just a bit weird for client devvs
Douglas Terabytehas joined
KevFair enough - I never found that bit particularly odd, but I might be in the minority :)
ZashI think that makes perfect sense. What's weird about it?
ZashOther than the historical thing where tons of things are advertised on and hooked onto the server JID, while newer things often go on the account JID
Douglas Terabytehas left
Ge0rGZash: maybe it's just because the perceived endpoint is the server, not my account
KevMy reading of this is that the minimally compliant thing to do is to error on iq get/set and swallow everything else, although I suspect errorring on a message (other than =error) might also be useful.
MattJI generally follow a policy of error for any unhandled/undelivered stanza
MattJSilent stanza loss is bad
ZashAnd Prosody doesn't silently discard CSNs, they get saved to offline storage 🙂
KevI considered bouncing everything, but bouncing presence seemed more likely to be unhelpful than helpful. Maybe I'm wrong about that.
KevThe really vital thing to bounce seems to be get/set.
KevIs there an argument for bouncing presence too?
MattJYes: silent stanza loss is generally bad
MattJTrying to subscribe to a server's JID should return an error (if the server doesn't support that)
MattJFor an example
KevThat's probably fair.
Guusas announced two weeks ago, I'm unavailable today.
ralphmSorry, got distracted
ralphm0. Welcome + Agenda
ralphmNyco and Guus sent regrets
ralphmAre we good with the agenda?
Ge0rGI'd like to provide a very brief update on the German gov't contact
MattJSounds good, and I'm good with the agenda
ralphmGreat, that's already on it
ralphm1. Discuss server setup
ralphmMattJ tried to follow up and then I failed to. We'll try again.
ralphm2. Messenger Regulation in Germany / EU
ralphmGe0rG: the floor is yours
Ge0rGI've talked to the person behind freie-messenger.de (another open protocols initiative), and obtained the contact of the respective person in the German ministry.
Ge0rGThe contact person is Dr. Schäfer, whom I've contacted and provided a brief info of what the XSF is and who I am. He's currently obtaining an overview of relevant companies and projects/initiatives, and we will schedule a phone call after my holiday, in ~3 weeks
Douglas Terabytehas joined
ralphmCool. Thanks for doing this!
SeveThank you very much Ge0rG, very appreciated, glad that you will be able to speak with him
ralphmI'll put the item on the backburner, pending that call, and am confident you'll come back when you have talked to Dr. Schäfer.
Ge0rGI'm going to schedule 15-30mins to introduce ourselves and to see where we might provide help
Ge0rGregardless of that, we should develop an idea of what we actually do want.
Ge0rGmake XMPP the default baseline interop protocol?
Ge0rGmake XMPP the #1 suggestion communicated to companies?
Ge0rGrequire all companies to use _the same_ interop protocol?
Ge0rGrequire all companies to use the same _officially standardized_ interop protocol?
Ge0rGI'm pretty sure we won't be able to put XMPP into actual law. And I'm pretty sure that won't be useful anyway.
ralphmThis is a good question indeed.
Ge0rGbecause who knows what the state-of-art will be in a decade or two
ralphmI agree that they won't mandate XMPP, but a well-known standard protocol suite would be good. Particularly if it isn't something like RCS.
Ge0rGralphm: I'm eager to hear your rationale against RCS after the meeting
ralphmSure. For clarity, that's my personal view.
Douglas Terabytehas left
Ge0rGMaybe Board should ponder a bit about the anticipated goals for the phone call
ralphmI'm also interested in what the community thinks about this. Anyone lurking here, or reading this after the fact, with an opinion, please let us know.
winfriedfor the record: I making a (probably unsuccessful) push right now to make XMPP the mandatory standard for message exchange in Dutch healthcare right now
Ge0rGwinfried: I'd love to hear your lessons-learned from that, on-list, via personal mail or otherwise, until June 22nd
ralphmwinfried: good to know. Would be interesting if you could share which arguments you use to make that case.
Ge0rG...and which aruments weren't good in the first place
Ge0rGralphm: it would be great to escalate that to The Community. Feel free to re-use parts of my initial Board mail.
mtavareswinfried, that would be great
ralphmWe also have other people in our community that have dealt with governmental and/or military requirements, so that could help as well.
winfriedRight now I am in a conference... I will post an e-mail on it to the memberlist
ralphm3. Fabian Sauter on SCAM
ralphmSeve added this one
SeveYes, he asked about joining in this very room
ralphmHe's doing the Berlin Sprints?
SeveAlthough nothing else was mentioned, if there was a purpose behind, or if we need help, etc
Severalphm, I met him at the Sprint there in Berlin, but I think he may be related to another one in another german city, not sure
SeveI expected him to be here today so we could talk about it, but he is not, unfortunately
ralphmSeve can you ask him to expand on what he wants to do on SCAM?
SeveYes, I will try to reach to him
ralphmI have no objections at this point, but a bit more than this would be good.
ralphm4. Tigase use of the XMPP logo
ralphmI believe I asked Peter this a while back, looking up what he said
ralphm“stpeter: Hey, sorry, I was offline yesterday. I would think the logo is under the IPR policy, if it's licensed under anything.”
ralphmnyco added this card, I don't know how that request came to us.
ralphmAdded info to the card
ralphm5. Roadmap page
SeveIt is basically this: https://github.com/xsf/xmpp.org/issues/564
ralphmWell, first of all, I believe that page is out of date.
MattJI think the page needs removal or an update
SeveWe may want to discuss if we have a roadmap or not, before thinking on even linking it from the sidebar
ralphmI'm curious if Council has an opinion on having a Roadmap like that.
MattJWe've consistently failed at Board determining a roadmap the past few years, but if Council wanted to put some content there it would be good
ralphmI wouldn't want to update it with without their involvement.
ralphmI need to think about this some more. dwd: could you (and Council) think about this, too?
ralphmI forgot this at the beginning: can one of you make minutes?
ralphmAlso, anything else?
SeveNot from me
MattJWho is collecting the use-case reports?
MattJThere was one I saw shared somewhere about Nintendo using XMPP for notifications
Ge0rGregarding SCAM applicants: wouldn't it be great to have them write a short application page on the wiki?
Ge0rGdoesn't need to be voted on by all members, just Board as-is
ralphmMattJ: I saw a tweet thread on that. Would be very interested to get a case study from them.
SeveIt may be a good idea to start with a wiki page with the use-case reports, with some links and such, so we all can contribute
ralphmThe talk itself was not allowed to be recorded :-(