XMPP Council - 2020-08-26

so this is taking about 100% longer than I anticipated already and I am not sure I'll make todays meeting

I'll probably be in right on time

It's time! :)

1) Roll Call

Hi

Hi

Hey

Hiya

excellent, full house

2) Agenda Bashing

any modifications?

None here

I've got an AOB, and it's called Compliance Suite 2021

oh my god

let’s move on

3) Editor’s Update - Ended LCs: - XEP-0352 (Client State Indication) ended on 2020-08-18 - XEP-0411 (Bookmarks Conversion) ended on 2020-08-18 (Those LCs were missing from the Editor’s update because of a mistake when using the LC tooling. The editors are now aware of the problem.)

4) Items for voting

4a) Decide on Advancement of XEP-0352: Client State Indication URL: https://xmpp.org/extensions/xep-0352.html Abstract: This document defines a way for the client to indicate its active/inactive state.

I think the feedback on list was mostly positive.

There was also rather little feedback.

Yeah, a bit thin

four different implementations

I assume that daniel is happy with it because he proposed it for LCing.

I'd still like to see the tribal knowledge codified, but not at the expense of delaying this XEP.

(dangerous assumption I know)

I agree with Zash that the tribal knowledge should go in an informational document instead of a standards track document

I did?

But yes I am

(very dangerous assumption apparently)

daniel, you or someone claiming to be you: https://mail.jabber.org/pipermail/standards/2020-January/036914.html ;-)

either way, I’m +1 on advancing

+1

Author in favour of tribal knowledge going into a different document

Zash: the good thing about Informational XEPs is that they are not carved in stone, so they can be a living document of everything we know is good / bad.

Council in favor of Author creating that document

No thanks

I felt that XEP-352 got "enough" feedback, myself. So +1 for advancing.

+1 for advancing

Ge0rG, no clear +1 from you yet, intentionally?

oh sorry

+1

thanks

4b) Decide on Advancement of XEP-0411: Bookmarks Conversion URL: https://xmpp.org/extensions/xep-0411.html Abstract: aThis specification describes a method to migrate to PEP based bookmarks without loosing compatibility with client that still use Private XML.

I actually intended to write +1 above, but then changed the wording to not contain the magic symbols

i think i'd rather just deprecate that one

🦗️

or ignore it for a while

daniel, elaborate?

Since it's set to be replaced by Bookmarks 2?

probably because of 0402

bookmarks 2 replace the conversion mechanism

/ has one too

ohh

It is a thing that exists in the wild tho

I was under the impression that this was Private XML / PEP Bookmarks 1 <-> Bookmarks 2

i'm not entirely sure I want to "send a message" by deprecating it

bookmarks 2 covers the bookmarks 2 conversion, optionally.

if it is a thing which exists, we can pull it to Draft and soon after Deprecate it in favour of 402?

but i'm also not keen on "sending a message" by advancing it

So, XEP-0411 got no feedback at all?

dwd, correct

no feedback at all

i mean it kinda does it's job in the wild right now

"no news is good news" ? :)

but as far as standards are concerned i don’t think it has a future

It's an interim standard at best, isn't it?

suggestion: instead of sending a message on our own, I post in the '411 LC thread and ask the community for feedback, making the Draft -> Deprecation route as our default clear? ✏

Yeah

I get the impression that (parts of) the community haven’t been happy with council perceivedly unexpectedly [without feedback from the community] sending messages ✏

Communication is hard

that's probably because our intent isn’t to send messages

right, we’re not here for any kind of message transportation

So, should we extend the LC and poke implementations more?

Zash, That would work for me.

obvious reminder that implementations are not necessary for LCs ;)

so, what do you folks want?

extend the LC?

extend and remind people that even if we draft we will propbably deprecate in a not too distant future?

Oh, it has implementations. That seemed clear. But no feedback suggests no interest.

+1 to what daniel says

+1 for extend & remind

i'm not sure that this will motivate people to provide feedback though. but we'll see

sure

let’s do that then, the editors can do that "in consultation with the approving body", I don’t think we need votes

5) Pending Votes

sounds good

+1 though if you need it for extending.

We have pending votes on PR#975

https://github.com/xsf/xeps/pull/975

by daniel only, actually

it doesn’t expire for another week, so no pressure here. If you need more time, that’s ok, and we can move on towards Ge0rG’s AOB

yes i'm aware. but still on list

ok, thanks

6) Date of Next

+1W WFM

+1w wfm

i probably won’t make it

+1 +1w.

+1w wfm, with a hard cutoff

ok, then I’d like to also quickly discuss who’ll fill in for me on the 9th and 16th of september

I will not have the time to make a proper agenda since on the 9th, we’re on vacation and on the 16th, we’ll move.

Forward planning: I'm off work the following week (ie, two weeks today) so might not be around.

and i'm entering a period with limited availability for ~1 month (I'm moving)

I'm going to be away from computers in the next weeks as well, but can't say for sure when.

Are we all moving, then? I am too, at some point.

crazy times

I'm not moving but renovating

Close enough.

that’s like moving but without leaving the place

Zash, you hvae to move house now.

dwd, no, zash has to do the meetings

All alone? :(

Zash: maybe you can get some voices from the floor

we could also agree to skip 9th/16th

though I’m not quite comfortable with skipping two weeks in a row

it might be 23rd and 30th for me.

I *could*, but cannot promise, maybe make an agenda on the 14th for the 16th with stuff which has aggregated in the meantime

ok, I see however that we’ll have difficulties to find a reliable chair in those weeks -- we’ll postpone this once more and find a solution next week

7) AOB

so I was in a supermarket recently, and they had Halloween ornaments on sale.

And that made me realize that it's time to create CS 2021

and you’re volunteering for that?

We had repeated discussions of whether the current CS format is good enough or not to achieve our goal.

Yeah, I can do that.

assuming that there wouldn’t be any changes; would we still want to have a new one just to bump the year?

Well. Has any server implementation claimed compliance with 2020?

Or client, indeed.

I hear that '215 may appear on it

I'd just like to know whether we should just move on with the current form or somebody has a suggestion that reduces the churn and workload on the author.

delegate to compliance.conversations.im? :-X

daniel: if there are no changes, I'd be fine to just change the title to include 2021

jonas’!

improving the format will be a lot of work and a lot of bike shedding

Ge0rG, As I say, I'd like to know whether anyone is "using" the existing one before bothering to do anything.

jonas’: when reading 0411 I realized that Some Editor didn't change the title of 0402 in the xml elements template.

I still think that it makes some sense to have snapshots of "what implementations do today" and then a separate "what we want to do in the future"

Ge0rG, ha! it’s a easter egg! I’ll update that, thanks ✏

Zash: that sounds like a task for a table, not for a XEP

or a survey and a blog post :)

Zash: also CS 2020 lists notable XEPs that are not mandatory.

a biannual gift basket?

Zash: you just volunteered, right?

😶️

dwd: if only we had compliance badges.

Or compliance badgers.

I thought we had one of those

https://www.youtube.com/watch?v=EIyixC9NsLI badgers!

ok. i think we should update, not change much, but introduce a new section for a/v calls

*new category

daniel, interesting

Sounds good daniel

They could charge around in the undergrowth at night, savaging non-compliant implementations.

daniel: that's a good suggestion!

can we also vote 0423 forward into Final?

i'd be happy to create that new section

Ge0rG, can you send me an email to put it on next week’s agenda?

but i'm not super keen on taking bike sheddy-feedback for the rest

Ge0rG, although, don’t we want to move it to deprecated rather?

we’re never going to find the two impls for Final

jonas’: we will move it to Deprecated in 2021

Ge0rG, final is not a prerequisite for deprecated

(and why are CSes not Informational anyways?)

that sounds as if Ge0rG and daniel will have a fun collaboration on the 2021 ones?

Zash, because, oddly enough, '0001 explicitly lists CS as Standards Track

-> https://xmpp.org/extensions/xep-0001.html#types-Standards-Track

jonas’: dwd asked for existing implementations of 0423, so I thought proposing it for Final would yield feedback from implementors

Ge0rG, I see

we’re running out of time

you can continue to discuss this here or in xsf@, but I’ll have to step out

8) Ite Meeting Est

but ye..

Thanks jonas’ (and Tedd)

where's jonas’?

Thanks everyone, good luck, stay healthy, don’t fall victim to the protocol badgers

Psst, Link Mauve, since you wrote https://modules.prosody.im/mod_bookmarks.html could you answer the LC plz?