XMPP Council - 2023-01-25

maybe a bit of short notice for an AOB / voting item, but I've copied CS'22 into CS'23 in the inbox, and the only addition is "changes since 2022: none".

https://github.com/xsf/xeps/pull/1267 ^

it's not published as a protoxep yet, so we cannot vote on it.

don't we need to vote about _accepting_ it as a protoxep?

no

the editor decides that

protoxeps are quite informal

we vote on accepting it as experimental

anything->protoxep->vote->experimental

Something that came up in a recent discussion: can/should the compliance suite reference specific XEP version requirements? ✏

yes

or is "latest version" implicitly required?

(IMO)

it may be, but it's better to state things clearly

For example, implementing the latest version of JMI would be a Bad Thing

But I'd like to require XEP-0313 1.0+ for "Advanced Server"

very sensible

I'd say it makes sense to have version requirements for experimental xeps, but not for stable ✏

larma, not fully sure, even stable may gain features

(MUC, for instance)

But once it's stable it should at least be fully backwards compatible

ack

meaning others don't have any issue by you implementing an older version

true

but the point of the compliance suites isn't just interop, but also experience

you can use a mobile client without a CSI-enabled server

given that feature tags are better than versions, maybe we should require certain feature-tags actually?

My point is rather that IF we allow experimental XEPs in CS (which I'd like to put a big question mark on), this should always be explicit. Alternatively we can also decide to not put experimental XEPs in CS which implicitly should then mean that CS is always pointing to at least 1.0

We had Carbons in there for a loooong time before it was promoted

I know what we did in the past, but that doesn't stop us from doing it better in the future

I think I agree with Ge0rG. I'd rather see NSs than versions? But that doesn't remove the question of whether experimental XEPs should be allowed or not

Regardless of what we *should* do, my motivation right now is that '313 has been listed in the compliance suites since it was experimental. It's now Stable, but I'd like it to be explicit that people must implement the Stable version.

Even if that's just a note in "Changes" (which should probably have been in the last edition?)

But we also recently discussed making version numbers explicit in general, hence my question

Maybe the tooling we have that judges compliance should just check that implementations claim compliance with the current x.y.*

based on DOAP and implemented XEP versions?

and combine that with a policy of not putting experimental stuff in here in the future

Yes

that sounds like I need to review all XEP refs in CS'23 for experimental status

you/someone

/a bot

Yes!

Make the CI do it

I still think NSs/features would be better listed than "1.0+" or than "latest" even.Not sure how to compare that with DOAP though :/

Maybe we need to start listing supported features in DOAP.

That would be significantly more effort

It doesn't have to be achieved right away, just like removing experimental stuff from CSs :P

`grep -o '&xep[0-9]\{4\}' inbox/cs-2023.xml|sort|uniq|grep -o '[0-9]\{4\}'| while read num ; do echo -n "XEP-$num: " ; xml2 < xep-$num.xml 2>/dev/null |awk -F = '/xep.header.status=/ { print $2;}'; done`

Exerimental/Deferred XEPs in CS'22: - XEP-0234: Jingle File Transfer - XEP-0353: Jingle Message Initiation - XEP-0357: Push Notifications - XEP-0398: User Avatar to vCard-Based Avatars Conversion

XEP-0225: Deferred XEP-0234: Deferred XEP-0333: Deferred XEP-0353: Experimental XEP-0357: Deferred XEP-0369: Experimental XEP-0374: Deferred XEP-0380: Deferred XEP-0384: Experimental XEP-0385: Deferred XEP-0386: Deferred XEP-0390: Deferred XEP-0392: Experimental XEP-0396: Deferred XEP-0397: Deferred XEP-0398: DeferredXEP-0409: Deferred XEP-0411: Deprecated XEP-0412: Obsolete XEP-0420: Experimental XEP-0423: Obsolete XEP-0433: Deferred XEP-0443: Obsolete XEP-0455: Experimental

quite a list.

Queue vote for Stable for all of them!

Ge0rG, you probably include the specifications of note not required for compliance and future development xeps?

larma: yes

The Obsolete ones in your list are previous years compliance suites 😀

oops ;)

referencing them should be fine

I think the ones actually part of the suites (the 4 I named) are the most imporant ones to review (decide if they should be in CS'23 and/or if they should advance to stable) ✏

larma, those four are all in wide usage afaik, so Stable away IMO

I don't think anyone implements all features of Jingle File Transfer

JMI has known issues tho?

Shouldn't widely used stuff be Final-ised even?

JFT: can't comment JMI: being fixed, stable before next edition should be possible Push: the current spec is awkward and I hope we can make a move on Push 2.0 this year, but probably as a new XEP. So we should probably advance what is deployed. Avatar conversion: can't comment

Sometimes I wonder if there should be a vcard-temp → vcard4 conversion ... XEP, feature, sentence, footnote ... something?

If we wanted to move current JFT to stable, I would remove §6.2, §6.3 and §6.4 before as we lack implementation of that. Alternatively I'd also like to note that JFT has recently become rather uninteresting in practice due to its device-to-device restrictions. When JFT is combined with SFS though, the unimplemented parts of JFT become relevant and will make JFT a reasonable transfer method again.

Hi

It's time

👋️

1) Roll call

Hello!

.

is Ge0rG around?

2) Agenda Bashing

yes

we had some proposals for the agenda but they came too late for this week. I'm going to add them to the next one

3) Editors update

none

4) Items for voting

none

5) Pending votes

none

6) Date of Next

I’m going to propose +2w

+1w wfm, also +2w

+2w wfm

since at least two of us are going to be traveling to brussels next week

+1w wfm, but I guess not for others :)

+2w wfm, too

7) AOB

Thanks Ge0rG for getting the compliance suite sorted

assuming no AOB then

8) Close

thank you all

Thanks all