XMPP Council - 2021-02-03

1) Roll Call

Hi

Ohai

Afternoon!

Good morning

\o/

2) Agenda Bashing

anything?

Bash it!

\o/

3) Editor’s Update

- Proposed XMPP Extensions: - Implicit WebSocket Endpoints

there’s already a good amount of discussion ongoing about that one on-list

speaking of which

4) Items for Voting

4a) Proposed XMPP Extension: Implicit WebSocket Endpoints URL: https://xmpp.org/extensions/inbox/xep-iwe.html Abstract: This document specifies implicit connection endpoints for XMPP over WebSocket (RFC 7395).

as you might’ve guessed, I hadn’t come around yet to read it, so I’m on-list

I'm not the biggest fan

Yeah, daniel you brought up a good point on list

and haproxy on yax.im:5222 tends to agree

I think I might be less oppossed to a XEP called "Recommendation for default port and path for websocket connections" informational XEP

which would address the point Sunny raised

and I do agree with his first paragraph I guess

Would that mean somebody running around and insisting every XMPP server changed their defaults?

sorry misspelled your name

dwd, yes

but the proposed XEP even more so I'm afraid

that's why I've put the "*recommendation* for default" in the title

to make it clear that it's just that

we can let it pan on on the list for a while I guess?

yes

on-list

I'm not sure we want to encourage anyone to listen on non-TLS websockets these days.

on-list

daniel, no problem - sounds good to me so far

dwd, that too

Which is ironic considering they only exist because I argued for them. :-)

dwd: I think the only reason would be for local development and CI/CD, but maybe there is a less inelegant solution for those

I'm skeptical, the no-SRV fallback thing seems like a mistake in hindsight, should we be repeating it?

Zash, I tend to agree

it causes annoying issues

But does it qualify for Experimental?

no idea, I’m still on-list

Zash. yes that's what I said on list.

daniel, I saw, and I agree.

but i think what i wrote above might be some sort of compromise because sonny does have a bit of a point

Right, so broadly, I think I'll veto, after skimming this. I'll post to the list on why, but as a summary:

I understand that ultimately the use case both for me and the editor is actually localhost/development so ws://service:5280/.well-known/xmpp-websocket would be fine there

159 of the 2726 client connections to yax.im use the non-SRV fallback.

Ge0rG, yes we can confirm ~10%

last time i checked

Pragmatism?

* Non-TLS websockets seem bad. * A "suck it and see" approach seems not something we want to encourage. * It's highly restrictive having the Websocket default to the same domain and a different port.

yes I was going to be +0 at best

what about: * it's an unprivileged port that a random local user could bind on * it's not IANA approved

only because i really try to avoid -1

ok, I think I need to bring it up again: I had my pidgin fall back to A/AAAA regularly because SRV lookup was failing while the local recursor was still booting. I don’t think that accounts for all of the connections you’re seeing to A/AAAA:5222, but such issues are still a factor and it shouldn’t be attributed to "laziness". They could be addressed by abolishing that endpoint and mandating SRV still (i.e. instead of fallback, retry SRV).

jonas’: old soho router resolvers lack SRV support. BTDT

jonas’, yes resolving SRV on crap wifis is an issue. but that isn’t the case for 156 over http

I think we can move on here.

I'd be up for a default path and default port for wss, as Daniel proposes, which - I think - satisfies much of the use-case for local dev.

dwd, I’ll note down your -1?

I hate to veto. I'll ost to the list and see if there are solutions, first.

ok

But I'm likely to, as far as I can see.

moving on:

4b) PR#1032: Data Forms Clarifications URL: https://github.com/xsf/xeps/pull/1032 Abstract: No description provided.

-1, it does not show sufficiently how this is a clarification and not a massive normative change; it introduces a precedent of requiring relative ordering of unrelated (i.e. different qname) elements which I *really* don’t want to see. ✏

on list. over the bike shedding of websocket i forgot to read this

jonas’, I don't think it's a new precedent, actually.

form-field type aware parsing of data forms does become more complex if the order is not specified ✏

dwd, source please

jonas’, The existing text says <reported/> described "the data to follow".

and it appears to be actually the norm to have <reported/> first, simply because most people copy the examples ✏

jonas’, Also, I think Sl{eek|i}XMPP already assumes an order, I noticed it in the code the other day.

wait wasn’t the lack of element ordering the reason we can’t use schemas?

dwd, it’s not clear from me that imposes a strict ordering requirement

daniel, that's why it isn't specified in the schema but in normative text

and for the record, I know of at least one implementation which does not guarantee the order and which would with that change become non-compliant.

jonas’, hence the clarification ;)

flow, I don’t believe, yet, that this is a clarification instead of a normative change

(and, obviously, as the XML document is the entire XML stream, the wording as written is invalid anyway)

(but that is easy to fix)

sure, everything which does clarify normative requirement that wasn't previously explicitly spelled out could be considered a normative change

jonas’, https://github.com/fritzy/SleekXMPP/blob/develop/sleekxmpp/plugins/xep_0004/stanza/form.py#L27 for example.

it's a trade-off

can we agree that the updated first commit of the PR is a clarification indeed?

flow, I don’t think that imposes a strict ordering during ingestion (as opposed to emission) of such stanzas

Ge0rG, I have to parse that in context first, one moment please

Anyway, happy to suggest this should be discussed on list, and not here.

Ge0rG, yes, I agree

on-list regarding the ordering requirement.

*sigh* I’ll see that I start a thread on that then

Ge0rG, yes

jonas’, I don't think we should be able to make a difference between ingestion and emission

moving on, let’s take that to the list

flow, Except at mealtimes.

yikes

mm. on-list

5) Pending Votes

I would tolerate implementations changing the order of first level stanza extensions, but not the order of arbitrary elements while en-route

there are still missing votes by daniel and dwd on the Service outage status protoxep, unless I missed any on-list

the vote expires today

jonas’, i voted on list

+1

in the minutes thread

thanks, didn’t see that yet

Oh, sorry. My bad, very much. +1, I'm pretty sure the general concept is fine.

dwd, thanks!

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

+1W WFM

that’s a quorum, thanks

7) AOB

none here

-

·

that was a lot of effort for saying "no" :)

alright then

8) Ite Meeting Est

thanks everyone!

thanks jonas’

thanks jonas’

Hrrrrrrrrrrrrr

FYI a future SRV2 XEP will support advertising websocket in conjunction with other connection methods, and routers and such will all support it very quickly because what HTTP/The Browsers (tm) want, they get ✏

And crappy firewalls will all magically implement this on day 1.

i guess the sad part is that this is likely to be true

false, they will implement the `HTTPS` record only.

the record name is still up in the air, it might end up being srv2 or https or http-svc or something else but that's just a minor detail

what matters is browsers will require it so everyone will fall all over themselves to implement it asap, many already have

It has been deployed already. It's too late now.

yep, something like 5% of sites already using it, support in all chrome channels etc

but that's fine, we'll use whatever The Browsers (tm) support, and we'll be set because of it :)

moparisthebest, link?

s/The Browsers/The Browser/

Zash, don't depress me :'(

pep., to, which? SRV2 ?

yeah

pep., https://mailarchive.ietf.org/arch/msg/dnsop/ldaCto09yaOuSXM92HgJhGqmPJw/

pep., always takes me a minute to find the latest version, I think https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02

thanks

(this also gets us encrypted client hello too, ie, hiding SNI and ALPN)

ietf.org is hosted at clownflare..

isn't everything? :(

:(

pep., no, www.ietf.org is hosted at cloudflare, but not ietf.org

I know this because there's a thread on a mailing list complaining about this.

re SVCB/HTTPS RRs, I guess we'll be able to do reverse roles now. HTTP on www.foo.tld served under foo.tld, and foo.tld serving XMPP and getting certificates properly. Useful in BYOD setups