https://logs.xmpp.org/council/2021-02-03?p=h#2021-02-03-16c5bf8a7f6e3e9d
1) Roll Call Present: Daniel, Zash, Dave, Georg, Jonas 2) Agenda Bashing None. 3) Editor's Update * Proposed XMPP Extensions: - Implicit WebSocket Endpoints 4a) Proposed XMPP Extension: Implicit WebSocket Endpoints - https://xmpp.org/extensions/inbox/xep-iwe.html Daniel isn't the biggest fan - Georg thinks Daniel brought up a good point [1] and his own HAProxy deployment seems to agree. Daniel might be less opposed to an Informational XEP titled "Recommendation for default port and path for websocket connections", which would address Sonny's point [2] - Dave asks whether that would mean every XMPP server would need to change its defaults - Daniel admits it would, though the current XEP makes an even stronger requirement, hence including 'recommendation' in the title. Dave isn't sure listening on non-TLS websockets should be encouraged these days - Daniel agrees. Georg thinks the only reason would be for local development and CI/CD, but there are possibly more elegant solutions for those. Zash is sceptical and thinks no-SRV fallback seems like a mistake in hindsight, so maybe it shouldn't be repeated - Jonas agrees and thinks it causes annoying issues. Zash asks whether it at least qualifies for Experimental - Daniel thinks so, as he expressed on-list - Zash agrees. Daniel thinks the Informational XEP might be a compromise, as Sonny does have a point. Dave might veto, but will post an explanation to the list [3] - in summary: non-TLS websockets seem bad; 'suck it and see' doesn't seem like an approach to be encouraged; and it's highly restrictive having the websocket default to the same domain with a different port. Georg finds that ~6% of client connections to yax.im use the non-SRV fallback - Daniel confirms he found ~10% the last time he checked for his server. Jonas mentions Pidgin has regularly fallen back to A/AAAA records because SRV lookup was failing due to the resolver not being ready - doesn't think that accounts for all of those connections, but such issues are a factor; could be addressed by abolishing that endpoint and mandating SRV (i.e. retry SRV instead of fallback). Georg says that old SOHO router resolvers lack SRV support. Daniel agrees that resolving SRV over crap wifi is an issue, but that's not the case for XEP-0156 (Discovering Alternative XMPP Connection Methods) over HTTP. Dave would be amenable to a default path and default port for WSS, as Daniel proposes, which should satisfy much of the local development use case. Jonas: [on-list] (haven't read it yet) Zash: [on-list] Georg: [on-list] Daniel: [on-list] (+0 at best) Dave: [on-list] (likely to veto) 4b) PR #1032 (Data Forms Clarifications) - https://github.com/xsf/xeps/pull/1032 Jonas sees this as a massive normative change, rather than the clarification it claims to be; it introduces a precedent of requiring relative ordering of unrelated elements. Dave doesn't think that's actually a new precedent - the existing text says the 'reported' element describes the data to follow; also recently noticed that SleekXMPP/SliXMPP already assumes an order. Jonas isn't sure that imposes a strict ordering requirement, and knows of at least one implementation which doesn't guarantee the order and would become non-compliant with such a change. The author, Flow, says that form-field type-aware parsing of data forms becomes more complex if the order isn't specified, and it appears to be the norm to have 'reported' first because people copy directly from the examples. Daniel thought the lack of element ordering was the reason schemas are non-normative - Flow says that's why it's specified in the normative text and not the schema. Jonas still isn't convinced this is a clarification - Flow suggests that any change which clarifies a normative requirement that wasn't previously explicitly spelled out could be considered a normative change; sees it as a trade-off. Flow would tolerate implementations changing the order of first-level stanza extensions, but not the order of arbitrary elements while en route. Georg seeks agreement that the updated first commit is indeed a clarification - Jonas and Zash agree. Dave is happy to discuss this further on the list - Jonas will reluctantly start a thread. Jonas: -1 Daniel: [on-list] (too distracted by the bike shed and forgot to read this) Georg: [on-list] Dave: [on-list] Zash: [on-list] 5) Pending Votes Dave votes on Service Outage Status: +1 (pretty sure the general concept is fine.) 6) Date of Next 2021-02-10 1600 UTC 7) AOB None. 8) Close Thanks everyone! [1] https://mail.jabber.org/pipermail/standards/2021-February/038115.html [2] https://mail.jabber.org/pipermail/standards/2021-February/038117.html [3] https://mail.jabber.org/pipermail/standards/2021-February/038127.html
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
