XMPP Council - 2020-06-17

It's this time of the week again!

quite

I have a hard cut in +30m due to a company-wide corona party, so let's not stretch too much today

Mexican beer?

I have no idea.

1) Roll Call

here

here

I’ve spotted a dwd already, so full house, excellent

2) Agenda Bashing

anything to modify?

assuming no

Not from me.

3) Editor’s Update - Calls in progress - LC for XEP-0338 (ends on 2020-06-30)

4) Items for voting

4a) PR#959: XEP-0156: reorganize stating XRD/JRD requirements URL: https://github.com/xsf/xeps/pull/959 Abstract: The reference to RFC 6120 was incorrect, what this really meant is RFC 6415. But instead of simply s/RFC 6120/RFC 6415/ here, I decided to reorganize stating the requirements of XRD and JRD a little.

This PR was amended to address council feedback from last session and is on the table again.

+1 on the PR now

+1

I think it improves the wording and could even count as editorial at this point.

+1, though if we want to change the last bit to read "additionally", that'd be possibly clearer.

oh, though, it makes JRD SHOULD instead of MAY

+1

(OPTIONAL = MAY)

Specifically, line 222 "It is possible to use an alternative JSON format..." - that always read that way but it might benefit from "additionally".

+1 on the PR

And yes, I noted that this raises JRD to a SHOULD, I assumed that was for interoperability reasons?

I don’t think we should be nitpicking wording here on this level

jonas’, And I'm not. Just noting.

fair

I was tempted to reply, so I felt the need to say that instead :)

raising the level for JRD makes sense to me in the web context, so no objections and we can move on

4b) PR#961: XEP-0030: Specify that the disco#info feature may not be explicitly set URL: https://github.com/xsf/xeps/pull/961 Abstract: Since #715 got rejected by council, we may as well drop the requirement to specify this explicitly. See-Also: https://github.com/xsf/xeps/pull/715

assuming my comments in the PR are addressed, I am still left to wonder what this improves. ✏

and I think we should set the bar for changing normative text of Final XEPs rather high.

jonas’, The problem this addresses is twofold: Firstly, it's clearly a bit weird to worry about discovering support for service discovery by first making a service discovery request to see if the response includes service discovery.

I mean, I see that announcing disco#info is kind of pointless in a disco#info response, but I also don’t see how this fixes any real-world problem.

Sure, disco#info might be redundant to advertise. But what jonas’ said.

jonas’, Secondly, ~none of our other XEP examples include this.

jonas’, So by making this optional, it immediately means our XEPs become conformant.

dwd, examples? are not normative

is there a mailing list post or something that describes the problem that this PR is trying to address?

I don’t see a problem with the latter. I advocated for blanket-including <!-- ... --> in disco#info examples if one is bothered by them not being complete (which I always felt to be obvious, because if every XEP had full disco#info examples we’d have much longer and more noisy texts for no gain)

daniel, not beyond that it’s the author’s follow-up to the rejection of https://github.com/xsf/xeps/pull/715

daniel, It's trying to document reality. Seems fine by me.

to me, it only documents reality of the examples in our documents; that it documents reality on the wire I’d like to see proven first.

That said, I'm -1 for the reasons jonas’ raiuses on the PR.

jonas’, There was lots of discussion around this. Seems most implementations proudly return disco#info, if only to ensure there's at least one feature present.

I'm on-list

-1, unless the author can find real-world issues which are solved by this PR. Specifically, if we don’t require disco#info and then stop requiring at-lesat-one element, it might break strict validators (the existence of which I could endorse given that this is a Final document and at-least-one is a MUST) for no good reason.

-1, agree with jonas’ & dwd

yes I agree with jonas’ here as well

I could go for "disco#info MAY be elided if other features are present" quite comfortably though.

as a sidenote, I would very much prefer us being explicit about disco#info replies specifically *not* being seen as complete in XEP examples, e.g. by using <!-- ... -->. ✏

sure

because you could turn this the other way ’round too, if you wanted to be pedantic: if '45 does not include pubsub features, is a MUC which announces them non-comformant?

jonas’, I'd be fine with that as well.

jonas’, No, you can't.

moving on

dwd, as devil’s advocate, I find a way to disagree, but I don’t want to waste everyone’s time on this stupid argument of mine :)

4c) PR#949: XEP-0157: Add status-addresses registrar entry URL: https://github.com/xsf/xeps/pull/949 See-Also: https://mail.jabber.org/pipermail/standards/2020-May/037443.html See-Also: https://mail.jabber.org/pipermail/standards/2020-June/037537.html

We also had this one a few weeks back, but there was discussion about extending the registry without consent from '68. See the second linked mailing list thread.

Hence, the validation stuff has been removed from the PR and converted into explicit wording, which I think is a reasonable compromise. ✏

This would allow us to move forward with extending '68 with validation and then amend the registry entry without breaking anything.

so +1

+1 for this. Noting my misgivings in general about how the Registrar is operating currently.

+1

you mean, not at all? :)

I endorse how you rejected a PR of mine to hack into the '45 registry on that grounds (to motivate me to fix the registry), but let other’s PRs pass :)

(no offense intended or taken, I am glad that you don’t veto this one) ✏

+1

Well, in this case the additional entry related closely to the XEP it's in.

Ge0rG, anything from you?

pregaming for the corona party?

assuming on-list then

(also due to lack of chat states)

5) Outstanding Votes - daniel and Zash are pending on PR#598 (expiring next week) AFAIK (<https://github.com/xsf/xeps/pull/598>)

other than that, just the pending ones from Ge0rG from this session

6) Date of Next

+1w wfm

+1w wfm

thooough I might have a very hard cutoff that day

and/or might find during the week that I need a replacement

no plans yet, but it’s a date which might cause high-priority plans to appear out of nowhere

+1 for 0157

Sorry, got distracted

woo

so if someone is happy to stand in as chair in case I miss the meeting, of course with a prepared agenda, that’d be good

I can be a stand-in chair.

thank you

If a chair *can* be a stand-in.

Please, people, it's not safe to stand in a chair.

i’m going to be on a train for the first time in forever next wednesday. but I think i'll be able to participate from my phone

daniel, wear your mask!

okay, we’ll see what we can manage

I don’t expect a lot of things to pop up anyways

7) AOB

Yeah wearing a mask is important to participate from a phone

anyone got any?

BTW https://github.com/xsf/xeps/pull/905 is on my radar screen, I just need to carve out time to look at it more closely.

Nah

stpeter, excellent

thanks for that

stpeter, while you're here, may I poke vrt vcard4? iirc it got into LC but then ???

I was wondering if we wanted to get a video call together for us, specifically *not* as a Council meeting, but as a more general chat.

Do always feel free to poke me (hard it necessary) about PRs.

dwd, that sounds like fun

I hear the video call stacks around the world got a lot better in the past few months

Obviously we'll need to spend some time considering what platform to use.

Zash: hmm, OK - as I recall, there wasn't strong interest at the time

FWIW I'll have a lot more time from next week

dwd, please no bikeshedding on that

if you want it to be a general chat

if nobody objects, I’d just suggest some jitsi instance, be it the official one or the ffmuc one

daniel: your optimism implies that you will be travelling abroad? ;)

Jitsi is fine by me. I'll sling some time suggestions around the Council list and see if there's interest there.

Clearly we should create a list of all possible videoconferencing options and randomly select using the procedures in https://tools.ietf.org/html/rfc3797

dwd, that sounds excellent, thank you

any other AOB?

(But seriously I'd just use Jitsi.)

(to clarify, when I say Jitsi, I generally refer to Jitsi Meet)

Ge0rG, no. just to the other side of country

(although I’m aware that’s incorrect)

assuming no council-relevant AOB, so

daniel: I don't think there was significant improvement of mobile network coverage in the last months ;)

8) Ite Meeting Est

have a splendid evening/remainder of the day everyone

Thanks jonas’!

Thanks jonas’, all

thanks jonas’

+1

the weather here is amazing if you can repress the nagging thoughts about dryness and climate change

oh. I had honestly forgotten that this is an issue

jonas’, BTW, I was looking at Gitlab/Github mirroring; I'd not realised that Gitlab can do that automagically for you these days.

dwd, to be honest, we’d hack that in CI jobs

to have more control over when a mirror action happens and to have it push based and to be able to constrain the permissions

what about the locust attack in east africa?

(using deploy keys instead of oauth permissions)

speaking of which: I really liked the gitlab proposal, and I don't care much if gitlab or github is our primary venue, and I'm okay with shutting down the other one altogether after the proof-of-concept phase

Ge0rG, thanks for the feedback

dwd, the main issue we’re having with the gitlab migration though is the lack of the CLA bot thing... we’ll have to improvise something there, unfortunately.

that’s really a bummer

It's curious really that there's no CLA bot

That seems to be a common thing to have CLAs (unfortunately?)

they don’t have an "app" platform at all

AFAIK

so that might be why

or it’s simply a popularity issue

maybe

I mean there is an implementation, but you have to do AWS Lambda webscale stuff and host it yourself, which I don’t quite appreciate right now

-> https://github.com/ScottLogic/gitlab-cla-bot/

yeah no thanks

exactly

I mean the API should give you enough info based on that, so maybe someone from the community wants to step up and build a thing *hinthint* *nudgenudge*

we could do a basic "hey, we don’t know you yet" comment thing in the CI with appropriate credentials, but it’d still lack any kind of interactiveness

kinda lost when it comes to searching for this specific problem ✏

re keywords

FTR: https://gitlab.com/gitlab-org/gitlab/-/issues/15899

If we can make CI figure out if somebody has signed we can "just" make it terminate early right? We don't actually need to have any API in issues for that I guess?

Maybe it's just a flag on the issue? dunno if we can set stuff like that

-> editor@