XMPP Council - 2022-01-12

hello ! apologies about last week, just the stupid alarm didn't go off, dumbest excuse possible

Hi

well, better for a council meeting than, say, for your mother's 50th birthday

It's time again

(completely made up example about calendar alerts not working. ha. ha.)

1) Roll call

👋️

Good morning!

i'll give you some time while i very quickly grab a coffee

good luck

let's time him to see what he calls quick

there must be some pun in there with quicksy, daniel, and calling, but I can't find it

also something about coffee and java...

so many possibilities should be there

i see you've been able to entertain yourself without me

2) agenda bashing

there is a late addition via pep and jonas’

3) editors update

a) An Update to XEP-0353 (Jingle Message Initiation) has been released. (https://xmpp.org/extensions/xep-0353.html)

cool update btw thanks to thilo for writing that up

4) items for voting

a) https://github.com/xsf/xeps/pull/1140

there is a normative change in there technically

yes

hence it goes by us :)

lgtm +1

I am +1, any other behaviour than the one described doesn't make sense

i personally thing it's fine. because what else would you do with those headers

i'd consider every implementation that doesn’t include the headers buggy

it also tightens down the corner case of multiple values for a single header being present

so +1 from me

do we have a rendered delta? ;)

I think some HTTP libs don't allow you to specify header order

Ge0rG, I find the github diff reasonably well readable

moparisthebest, order of values, not order of headers

but that's a them-problem I reckon, so also +1 from me

oh

moparisthebest, that's a very good point

> I think some HTTP libs don't allow you to specify header order that crossed my mind too

I have a small nitpick about "These headers MUST be included in the HTTP PUT request" - it's not clear whether it relates to the headers that are in the XML or to the three allowed header names.

-1: The wording has a bug which can easily be misread as "the headers' order must be preserved", while the intent was to preserve the order of values of a given header, if multiple values are given ✏

Ge0rG, yep, that was another bit

I'll propose an updated wording in a minute

pep., I'll hijack your PR if I may

oh, well yea it would be best if header order wasn't required, especially if it wasn't intended

also how do you sign a HTTP header?

presumably you sign the header's value, but again, some wording

there are schemes where signatures are sent out-of-band, and that wouldn't be compatible

proposed fix for the wording: https://github.com/xsf/xeps/pull/1140/commits/85ff424a9e2aab8a4aab56fcd490c341ae50b3a5

Ge0rG, there are standards for that, let's not go into that ;)

thanks jonas’ for the hotfix 🙂

Ge0rG, I'm sure HTTP header signing schemes are compatible with header reordering, as relative header order is AFAIK not guaranteed

jonas’: there be dragons

HTTP's dragons, not ours :)

ok now I'm no-hesitation +1 :D

I'll be +1 with my patch

ok. i'll restart voting *with* jonas' fix

Ge0rG, we already tighten down the available headers, which restricts what can be done anyway

+1

jonas’: I'm +1 with your patch

Ge0rG, tell that to daniel, I'm not chair anymore :)

jonas’: I'm pretty sure that most http libraries won't honor the order of equally named headers

+1 here as well

daniel: +1 ;)

i recorded your vote Ge0rG

+1 again

Ge0rG, let's not get into that here

ok great. moving on

b) XEP-0030: remove security considerations preventing requests on a bare JID (https://github.com/xsf/xeps/pull/1145)

i'm on list for that

note that there's already a thread on list

but I, too, am on-list

haven't gotten around to read it yet

also on-list, worries me a bit

(the thread has the subject [XEP-0030] we can't get basic information on a bare JID without presence subscription, it's also linked from the PR)

ack, -1 is my first inclination, too

on-list

but I'll read the rationale first, so please don't record that yet

on-list

ok thank you

5) Pending votes

Ge0rG and moparisthebest are pending on the four xeps proposed last week

Yup.

note the pubsub namespace one has technically already been vetoed

I'm +1 on all of them except Proposed XMPP Extension: PubSub Namespaces where I'm -1

I'm not sure what I voted on PubSub Namespaces, but the discussion has confirmed my perception that it should be -1 until fixed up as discussed on list

I'm still on-list

I'm 0 on pubsub-ns, I feel there is need for clarification, but this is not how it should be

jonas’, i did record a -1 for you

excellent

speaking of, can I get a link to the current spreadsheet of doom? I lost it somehow :)

it's useful for editor work

for logs sake I'm +1 on: https://xmpp.org/extensions/inbox/compatibility-fallback.html https://xmpp.org/extensions/inbox/call-invites.html https://xmpp.org/extensions/inbox/replies.html

https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit#gid=0

moparisthebest, thanks :)

moparisthebest, yes thank you i recorded that

also I swear I voted -1 on https://github.com/xsf/xeps/pull/1126 but it was rejected already so meh :)

6) Date of next

+1w wfm

+1w wfm most likely

good for me

wfm as well

+1W WFM, but I'll be on vacation the following two weeks

7) AOB

covid19: "well, we'll see about that"

no AOB from me

no AOB

same here

8) Close

Thank you everyone

Thanks daniel 🙂

Thanks daniel :)

thanks!

as an aside, the http header thing was fresh in my mind, because curl preserves both header order and case, and they recently added a backend using hyper (rust http lib) which preserves neither, which curl considered a bug :)

What else would I use to craft special http requests than curl. I would consider this a bug as well if they lost those features...

larma, openssl s_client ;)

I just use curl for virtually everything http based

jonas’: that's already my XMPP client of choice :)

larma, see, it's a multi-protocol client ;)

larma, great job on all these XEPs by the way, seeing XEPs created with actual public code behind them is infinitely better than "in theory" XEPs

“jonas’> pep., I'll hijack your PR if I may” < Sure.