dwd"I know this because there's a thread on a mailing list complaining about this." - catch-all for any subject (and more or less any mailing list, but certainly IETF Discuss)
jonas’1) Roll Call
jonas’I am, too
jonas’I heard dwds textvoice just now and Ge0rG sent apologies, so I assume we can go on
jonas’2) Agenda Bashing
jonas’3) Editor’s Update
dwd(I am here, just finishing a call about an entertaining security issue we uncovered)
jonas’- New XEPs:
- XEP-0455: Service Outage Status
jonas’dwd, that sounds very entertaining
jonas’4) Items for voting
jonas’5) Pending Votes
jonas’The data forms PR is lacking discussion / voting.
jonas’I apologize, the weekend was… interesting to say the least. I didn’t get around to start a thread. I might tonight or reply to the minutes.
jonas’Does anyone want to cast votes on that or the Web Socket Endpoints protoxep in the meantime?
dwdI hope interesting in a good sense, but i'm sensing that's wishful thinking.
jonas’it is indeed
dwdYeah, I'm going to veto the websockets endpoint one as noted on the mailing list.
dwdAnd also on the assumption that a different proposal around this will emerge.
danielI’m glad dwd is doing the vetoing so i don’t have to
dwd(So a veto without prejudice, as it were).
danielbut i agree that a new xep is the better aproach
jonas’dwd, can you state your rationale here for the record please?
dwddaniel, You still should, in case I withdraw or you have other interesting reasons to veto.
dwdjonas’, I stated them on list for the record, but loosely it implies a server default of listening on unencrypted sessions, and devalues XEP-0156.
dwdjonas’, I am expecting something closer to a "suggested defaults" with both test and production recommendations.
jonas’dwd, yep, I assumed it was on-list, but me (or Tedd) digging into the thread to find it is suboptimal :)
jonas’sounds good to me
jonas’there is this proposal: https://github.com/xsf/xeps/pull/1035/files
daniel-1: Having a XEP that defines recommendation for default ports and paths is interesting but the proto xep goes well beyond that and tries to influence client behaviour which might lead to the degradation of doing things properly ake 156
danielessentially everything we discussed last week
jonas’-1: Let’s not repeat the mistake of the A/AAAA fallback here when there’s no evidence that it’s needed for practical interoperability concerns.
danielplus a agree with dwd in that haevily editing the current proto xep over starting fresh is not the best path
Kev(FWIW, I’m not convinced the A/AAAA fallback was a mistake at the time)
danielespecially once it's out there it's out there. and any edits might take time
dwdI can see defaults are really interesting from an ease-of-test and ease-of-deplyment case, and recommendations for production deployment are great too. But that seems a rather fundamentally different XEP than the one we have now.
jonas’.well-known requires some IANA interaction, right?
ZashSorry, I'm inexplicably tired all day and having trouble following. What are we voting on?
Kevdwd: Why are recommendations for a production deployment great? If a client is doing lookups, isn’t it entirely deployment’s choice, and so one recommendation can’t be better than another?
danielwhich doesn’t have to be a bad thing, re iana
dwdZash, Websocket ProtoXEP missing votes.
jonas’Zash, we’re currently discussing the websockets protoxep
dwdKev, For example, suggesting that websockets run on port 443 over TLS is useful advice.
dwdKev, And materially better than port 5280 without TLS.
jonas’(that would be Informational, and not Standards Track, though)
ZashInformational thing that suggests defaults sounds fine
Kevdwd: TLS is absolutely good advice. I’m not sure if 443 is, but I can at least see an argument for it. Any other port would be a bad thing to recommend though, I think.
jonas’is anyone from the present people interested in taking on the work to do it?
dwdOh, gosh, no. I was assuming either of flow or Sonny would take that on.
KevBut yes, a XEP saying “Look, always do TLS. And 443 might be a good choice” seems much less likely to be harmful than some other things might be.
ZashAren't there RFCs saying that (always TLS!!!) already?
jonas’sonny looked interested in moving this towards a default recommendation
ZashSo. I can vote -1, fallbacks bad, tls good, what everyone else said, try again to the previous proposal.
jonas’then we’ve got all votes collected
jonas’I assume we’re going to discuss the data forms thing on-list then?
danieli don’t see how this would not require a namespace bump
ZashBumping dataforms? Oh glob
dwdThe data forms thing? Seemed OK to me, mind.
jonas’yes, and kill <reported/> while we’re at it
danieli mean we've been pretty liberal with the word clarifying in the past…
jonas’to the point that I’d like to ban that word from xeps PRs
الياباني مغيرةhas left
dwdWell, either people *do* care about the order or they don't. A way to "fix" the issue would be to say SHOULD send in order, MUST accept in any order.
jonas’I could live with that
dwdBut yeah, this needs a list discussion.
jonas’ok, let’s move it there then
jonas’6) Date of Next
danielbut if you must accept it in any order why send it in one?
jonas’dwd still checking his schedule I presume?
jonas’… anyway, three’s a quorum
jonas’has anyone got any?
jonas’talking to his echo
ZashI've got nothing.
jonas’8) Ite Meeting Est
jonas’Thanks Tedd for the Minutes :)
jonas’(they arrived just now and I’ll reply re data forms)
ZashThanks Tedd, jonas’, all.
jonas’FTR, replied to the minutes thread re data forms