XMPP Council - 2020-04-15

1) Roll Call

Hi

pinging Zash

Here

also, hi everyone :)

2) Agenda Bashing

any additions?

I can't think of anything.

sorry, got distracted reading daves email

3) Editor’s Report

- Expired calls: None - Calls in progress: - LC for XEP-0357 (Push notifications) ends at 2020-04-15 - New ProtoXEP: Room Activity Indicators

by now, the LC has expired

4) Items for Voting

4a) Proposed XMPP Extension: Room Activity Indicators URL: https://xmpp.org/extensions/inbox/room-activity-indicators.html Abstract: This specification describes a lightweight mechanism for activity notifications in MUCs.

And I forgot to read and comment on the Push thread.

On list

on list

on list

on List

alright

4b) PR#924 Title: Change service discovery flow to use account instead of server URL: https://github.com/xsf/xeps/pull/924 Description: The rationale for this is that blocking is an account-level feature. It may not be offered for all accounts, even if the server supports it.

I expect some controversy on this one

Muh backwards compat!

very controversial indeed

on-list

I default to +1

For hysterical raisins, you often disco your server's JID to find out what's supported for your current session.

I’d like to gradually change that

I don't think doing so prohibits returning the right results to the right entity, so I think that the motivation listed here doesn't lead to this patch as a result (although other motivations may).

I like the general pattern of disco#info going to the same as the rest of the protocol

Zash, to the same what?

JID.

ah, that

+0

Packet loss somewhere between brain and keyboard.

Kev, so in my puristic view, disco#info for an entity should look the same no matter who’s asking (* conditions apply).

I'm not very on board with changing draft xeps

I think I'll have to on-list and stew for a while.

Maybe, but the first two XEPs that I picked at 'random' to check (191, 258) show the same behaviour of advertising on the server JID.

Even though what the PR is doing would be 'more correct'

So I think changing one XEP in isolation is probably not the right thing to do here without wider thought.

I guess we’ll have to take this to the list for the wider community then

Sounds good.

fine by me

So I’d like to cancel the vote so that we’re not bound to the 2w timeline on this starting today after community feedback.

Ok

alright, moving on

4c) Decide on Advancement of XEP-0357: Push Notifications URL: https://xmpp.org/extensions/xep-0357.html Abstract: This specification defines a way for an XMPP servers to deliver information for use in push notifications to mobile and other devices.

-1

daniel, rationale?

-1, I think the arguments brought up against this using PubSub syntax and that making it unnecessarily hard to understand are sound and this needs work.

Feedback came up that hasn't been addressed

so back to experimental with this one

is anyone taking ownership of it?

Kev, ?

do you have resources to shepherd it?

(and/or can you get lance to do it)

As I said on list it probably wouldn't be a bad idea to just start from scratch

I haven't even replied to the LC myself.

Kev, you’re an author though, which is why I’m asking you :)

Lance wanted to retire from this one.

alright

Not that I'm volunteering to do so. But that makes the question of ownership unnecessary

Yeah, I meant as an illustration of time for this. Lance wanted another author listed so he could avoid doing things. I thought I'd be spending time working with it, so volunteered, but have ended up not touching it since.

OK

it would be good to get someone actually involved with implementations around this to do the work

Indeed.

that’d be mobile client devs and server devs primarily

I have conveniently not touched this for years, so not it! /me hides

Both of which I am, obviously, but am very short of cycles at the moment.

getting some input from the Xabber folks would also be good

Well the tigase people introduced something at summit. We should probably encourage them to actually write that down in xep Form

daniel, you’re probably more familiar with that than I am, and also conveniently a mobile dev; can you contact them and figure out if they will do that, and if they won’t, post a call to standards@ for someone to do it?

Yes

thank you

alright, moving on

5) Pending Votes

Dave cleared his off the list in the last mail

He made valid points about PR#913 and I’m going to fix that up and re-propose it.

other than that, we’re good to go I think.

6) Date of Next

+1w wfm

Wfm

works for me

7) AOB

none from me

I remembered what I wanted to do last week. Ask editor to please LC XEP-0320: Use of DTLS-SRTP in Jingle Sessions XEP-0339: Source-Specific Media Attributes in Jingle

who’ll shepherd that?

or do you have contact to Philipp Hancke?

He has been somewhat active on the list lately

But I think they will be rather uncontroversial and just go through

It's just meta data annotations

by default, only the approving body or the author can request an LC; in the absence of the author, we need a shepherd. and we’re past the voting stage for today

not sure what to make of that

OK. Put it on the agenda for next week

I thought Editor could call them

daniel, if you can get Philipp to ask the Editor to LC them before that, we can start it early.

from my reading of '1 not

oh wait

> The Approving Body must agree that the XEP is ready to be considered for advancement.

nevermind me, so, we need to vote on this

putting it up for next week

Thanks

anything else?

assuming not

8) Ite Meeting Est

Thanks everyone

Thanks all

Thanks