-
moparisthebest
hello ! apologies about last week, just the stupid alarm didn't go off, dumbest excuse possible
-
daniel
Hi
-
jonas’
well, better for a council meeting than, say, for your mother's 50th birthday
-
daniel
It's time again
-
jonas’
(completely made up example about calendar alerts not working. ha. ha.)
-
daniel
1) Roll call
- jonas’ is here
-
larma
👋️
-
Ge0rG
Good morning!
-
daniel
i'll give you some time while i very quickly grab a coffee
-
jonas’
good luck
-
moparisthebest
let's time him to see what he calls quick
-
jonas’
there must be some pun in there with quicksy, daniel, and calling, but I can't find it
-
moparisthebest
also something about coffee and java...
-
jonas’
so many possibilities should be there
-
daniel
i see you've been able to entertain yourself without me
-
daniel
2) agenda bashing
-
daniel
there is a late addition via pep and jonas’
-
daniel
3) editors update
-
daniel
a) An Update to XEP-0353 (Jingle Message Initiation) has been released. (https://xmpp.org/extensions/xep-0353.html)
-
daniel
cool update btw thanks to thilo for writing that up
-
daniel
4) items for voting
-
daniel
a) https://github.com/xsf/xeps/pull/1140
-
daniel
there is a normative change in there technically
-
jonas’
yes
-
jonas’
hence it goes by us :)
-
larma
lgtm +1
-
jonas’
I am +1, any other behaviour than the one described doesn't make sense
-
daniel
i personally thing it's fine. because what else would you do with those headers
-
daniel
i'd consider every implementation that doesn’t include the headers buggy
-
jonas’
it also tightens down the corner case of multiple values for a single header being present
-
daniel
so +1 from me
-
Ge0rG
do we have a rendered delta? ;)
-
moparisthebest
I think some HTTP libs don't allow you to specify header order
-
jonas’
Ge0rG, I find the github diff reasonably well readable
-
jonas’
moparisthebest, order of values, not order of headers
-
moparisthebest
but that's a them-problem I reckon, so also +1 from me
-
jonas’
oh
-
jonas’
moparisthebest, that's a very good point
-
jonas’
-1✎ -
daniel
> I think some HTTP libs don't allow you to specify header order that crossed my mind too
-
Ge0rG
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.
-
jonas’
-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 ✏
-
jonas’
Ge0rG, yep, that was another bit
-
jonas’
I'll propose an updated wording in a minute
-
jonas’
pep., I'll hijack your PR if I may
-
moparisthebest
oh, well yea it would be best if header order wasn't required, especially if it wasn't intended
-
Ge0rG
also how do you sign a HTTP header?
-
moparisthebest
presumably you sign the header's value, but again, some wording
-
Ge0rG
there are schemes where signatures are sent out-of-band, and that wouldn't be compatible
-
jonas’
proposed fix for the wording: https://github.com/xsf/xeps/pull/1140/commits/85ff424a9e2aab8a4aab56fcd490c341ae50b3a5
-
jonas’
Ge0rG, there are standards for that, let's not go into that ;)
-
larma
thanks jonas’ for the hotfix 🙂
-
jonas’
Ge0rG, I'm sure HTTP header signing schemes are compatible with header reordering, as relative header order is AFAIK not guaranteed
-
Ge0rG
jonas’: there be dragons
-
jonas’
HTTP's dragons, not ours :)
-
moparisthebest
ok now I'm no-hesitation +1 :D
-
jonas’
I'll be +1 with my patch
-
daniel
ok. i'll restart voting *with* jonas' fix
-
jonas’
Ge0rG, we already tighten down the available headers, which restricts what can be done anyway
-
larma
+1
-
Ge0rG
jonas’: I'm +1 with your patch
-
jonas’
Ge0rG, tell that to daniel, I'm not chair anymore :)
-
Ge0rG
jonas’: I'm pretty sure that most http libraries won't honor the order of equally named headers
-
daniel
+1 here as well
-
Ge0rG
daniel: +1 ;)
-
daniel
i recorded your vote Ge0rG
-
moparisthebest
+1 again
-
jonas’
Ge0rG, let's not get into that here
-
daniel
ok great. moving on
-
daniel
b) XEP-0030: remove security considerations preventing requests on a bare JID (https://github.com/xsf/xeps/pull/1145)
-
daniel
i'm on list for that
-
jonas’
note that there's already a thread on list
-
jonas’
but I, too, am on-list
-
jonas’
haven't gotten around to read it yet
-
moparisthebest
also on-list, worries me a bit
-
jonas’
(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)
-
jonas’
ack, -1 is my first inclination, too
-
Ge0rG
on-list
-
jonas’
but I'll read the rationale first, so please don't record that yet
-
larma
on-list
-
daniel
ok thank you
-
daniel
5) Pending votes
-
daniel
Ge0rG and moparisthebest are pending on the four xeps proposed last week
-
Ge0rG
Yup.
-
daniel
note the pubsub namespace one has technically already been vetoed
-
moparisthebest
I'm +1 on all of them except Proposed XMPP Extension: PubSub Namespaces where I'm -1
-
jonas’
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
-
Ge0rG
I'm still on-list
-
larma
I'm 0 on pubsub-ns, I feel there is need for clarification, but this is not how it should be
-
daniel
jonas’, i did record a -1 for you
-
jonas’
excellent
-
jonas’
speaking of, can I get a link to the current spreadsheet of doom? I lost it somehow :)
-
jonas’
it's useful for editor work
-
moparisthebest
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
-
moparisthebest
https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit#gid=0
-
jonas’
moparisthebest, thanks :)
-
daniel
moparisthebest, yes thank you i recorded that
-
moparisthebest
also I swear I voted -1 on https://github.com/xsf/xeps/pull/1126 but it was rejected already so meh :)
-
daniel
6) Date of next
-
daniel
+1w wfm
-
jonas’
+1w wfm most likely
-
moparisthebest
good for me
-
larma
wfm as well
-
Ge0rG
+1W WFM, but I'll be on vacation the following two weeks
-
daniel
7) AOB
-
jonas’
covid19: "well, we'll see about that"
-
jonas’
no AOB from me
-
moparisthebest
no AOB
-
larma
same here
-
daniel
8) Close
-
daniel
Thank you everyone
-
larma
Thanks daniel 🙂
-
jonas’
Thanks daniel :)
-
moparisthebest
thanks!
-
moparisthebest
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 :)
-
larma
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...
-
jonas’
larma, openssl s_client ;)
-
moparisthebest
I just use curl for virtually everything http based
-
larma
jonas’: that's already my XMPP client of choice :)
-
jonas’
larma, see, it's a multi-protocol client ;)
-
moparisthebest
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
-
pep.
“jonas’> pep., I'll hijack your PR if I may” < Sure.