-
Ge0rG
It looks like I'll be late and/or distracted
-
jonas’
nted✎ -
jonas’
noted ✏
-
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
-
daniel
Hi
-
Zash
Here.
-
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’
anything?
-
Zash
silence
-
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 None.
-
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.
-
Zash
SGTM
-
jonas’
Does anyone want to cast votes on that or the Web Socket Endpoints protoxep in the meantime?
-
dwd
I hope interesting in a good sense, but i'm sensing that's wishful thinking.
-
jonas’
it is indeed
-
dwd
Yeah, I'm going to veto the websockets endpoint one as noted on the mailing list.
-
dwd
And also on the assumption that a different proposal around this will emerge.
-
daniel
I’m glad dwd is doing the vetoing so i don’t have to
-
dwd
(So a veto without prejudice, as it were).
-
daniel
but i agree that a new xep is the better aproach
-
jonas’
dwd, can you state your rationale here for the record please?
-
dwd
daniel, You still should, in case I withdraw or you have other interesting reasons to veto.
-
dwd
jonas’, I stated them on list for the record, but loosely it implies a server default of listening on unencrypted sessions, and devalues XEP-0156.
-
dwd
jonas’, 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
-
daniel
essentially 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.
-
daniel
plus 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)
-
daniel
especially once it's out there it's out there. and any edits might take time
-
dwd
I 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?
-
Zash
Sorry, I'm inexplicably tired all day and having trouble following. What are we voting on?
-
Kev
dwd: 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?
-
daniel
which doesn’t have to be a bad thing, re iana
-
dwd
Zash, Websocket ProtoXEP missing votes.
-
jonas’
Zash, we’re currently discussing the websockets protoxep
-
dwd
Kev, For example, suggesting that websockets run on port 443 over TLS is useful advice.
-
dwd
Kev, And materially better than port 5280 without TLS.
-
jonas’
(that would be Informational, and not Standards Track, though)
-
dwd
jonas’, Indeed.
-
Zash
Informational thing that suggests defaults sounds fine
-
jonas’
agreed
-
daniel
+1
-
Kev
dwd: 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?
-
dwd
Oh, gosh, no. I was assuming either of flow or Sonny would take that on.
-
Kev
But 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.
-
Zash
Aren't there RFCs saying that (always TLS!!!) already?
-
jonas’
sonny looked interested in moving this towards a default recommendation
-
Zash
So. 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?
-
daniel
i don’t see how this would not require a namespace bump
-
Zash
Bumping dataforms? Oh glob
-
dwd
The data forms thing? Seemed OK to me, mind.
-
jonas’
yes, and kill <reported/> while we’re at it
-
jonas’
win-win :D
-
daniel
i 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
-
Zash
Haha
-
dwd
Well, 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
-
daniel
+1
-
dwd
But yeah, this needs a list discussion.
-
jonas’
ok, let’s move it there then
-
jonas’
6) Date of Next
-
jonas’
+1w wfm
-
daniel
but if you must accept it in any order why send it in one?
-
daniel
+1w wfm
-
Zash
+1w wfm
-
jonas’
dwd still checking his schedule I presume?
-
jonas’
… anyway, three’s a quorum
-
jonas’
7) AOB
-
jonas’
has anyone got any?
- jonas’ talking to his echo
-
jonas’
assuming none
-
Zash
I'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)
-
daniel
thanks all
-
Zash
Thanks Tedd, jonas’, all.
-
jonas’
FTR, replied to the minutes thread re data forms