XMPP Council - 2017-09-20

Are we meeting in a few minutes?

i think so

oh it’s wednesday

👍

1) Roll call

here

SamWhited, daniel, Dave Cridland, Link Mauve, ping

I am partially here and will be fully here in a few minutes

Tobias: ?

Dave Cridland, wanted to know whether you are there, for the roll call

appears so

2) Minute Taker

any volunteers?

Hi, I’m here too.

i can do it

jcbrand, or are you available for it?

Yes, I'm available

Tobias, daniel ^

thanks

3) Vote on accepting "Consistent Color Generation" as Experimental XEP

I'll vote on list

+1

+1

4) Vote on accepting "Jingle Encrypted Transports" as Experimental XEP

I'll vote on list

I wonder if that TODO at the bottom means it's going to be split into separate XEPs, or just separate sections in this XEP? If new XEPs are coming anyways do we want to bother accepting it?

3) +1

SamWhited, from my understanding on the mailing list, vanitasvitae said he’d add more XEPs specifying how to use the JET framework with OMEMO etc.

4) I’ll vote on list.

(I haven’t read it yet.)

(The new version.)

(but don’t take only my word for it)

I'll just be on list then and ask first

on list

or double check the discussion

5) Discuss removal of Groupchat 1.0 protocol from XEP-0045 ( request by jonasw )

I was only proxying that request

the original request is from a discussion in the xsf@ MUC, I think dwd was present

and maybe SAm

but I can give some details if needed ( Ge0rG can too if he’s around)

jonasw: please do. I don't know what this is about

okay, will do

the origin of the discussion was that currently there’s no way for a client to know whether it’s still joined (think s2s errors and other state desync)

(no reasonable way that is)

then there was the suggestion to simply send presence to ensure that one is still joined

the issue with that is that it could be interpreted as a Groupchat 1.0 join, which would not be desired

from this originated the suggestion to remove that Groupchat 1.0 protocol entirely

which would have the advantage that clients are safe against accidental Groupchat 1.0 joins when they desync

ähm...but just removing it from the XEP without incrementing namespace or so won't allow clients and rooms to apply that logic, will it?

that’s mostly it I think

Are there still clients that support "groupchat 1.0"?

the argument was that Groupchat 1.0 does *most likely* not exist anymore anyways

Personally, I'm fine breaking compatibility with any clients that still support groupchat 1.0.

ahh

peter: Yes, implicitly.

Because the fact that a presence chengae will cause a rejoin after an S2S blip is remarkably useful

groupchat 1.0 join is a presence without the <x/>?

daniel, exactly

If you removed that, suddenly lots of people wouldn't be in MUCs when they thought they were.

Kev, is it? I think it’s not useful

you’d want to specify the needed history instead

Anyway, this is a hack.

If you want to change xep45 to allow you to know if you're in the room, add an iq to that effect.

getting a proper error back and then making a proper join with history etc. sounds more reasonable

Kev, that was also discussed, but is a separate topic

Removing legacy joins is very much the wrong option here, I think.

alright..do we want to continue that discussion on standard ML?

That sounds sensible.

That'd be the appropriate place, I think.

alright

good idea

FWIW I agree with Kev.

6) Consider advancing XEP-0387: XMPP Compliance Suites 2017 to Draft (added by SamWhited )

Sounds sensible to me, i think we should issue a LC if other draft requirements are met

not sure if this is a blocker but the xmpp compliance suite requires the bookmark xep which can't be implemented right now

I would like to start having compliance suites created and advanced by the beginning of the year (eg. 2018 suites would be created and a recommendation by January 1, 2018). I think a sensible place to start trying to do that would be to make sure the 2017 ones are advanced

daniel: bookmark can't be implemented?

because it depends on pep functionality that doesn't exist

and which people don't want to have in pep

but it's fine with me if we start a last call on xep387

i can bring this up in the last call

daniel, it could depend on the previous version, which was using 0049.

Which is AFAIK how every client implements it.

Sounds good; thanks. I think using pubsub at all for bookmarks is RECOMMENDED, so I'm not sure if it's a problem. We can discuss on list.

Can we get MIX out of 387, then?

sound sensible then

so we're all in favour of issuing a LC?

MIX has been out of it for a long time (and I still think that was a bad decision, but I did it)

SamWhited, also, why are the compliance suites standards tracks, instead of informational?

SamWhited: ah, thanks. Didn't get that update.

Link Mauve: I'm not sure, they include 2119 language?

Hmm…

Anyways, +0 for LC (seeing as I'm the author) and we can discuss other things on list unless anyone sees a reason to block that really needs to be discussed now

alright

7) Issue a new LC for XEP-0352: Client State Indication , based on https://github.com/xsf/xeps/pull/427

any objections to this?

+1 for LC

+1

i'm also +1

+1

alright. Let's come to an end as we're already exceeding half an hour.

8) Date of next

Same time next week?

wfm

I won’t be here next week, I’m on vacations.

wfm

wfm

Link Mauve, happy to vote on list?

Sure. :)

alright

9) AOB

None from me

great

thanks everybody

Good stuff; thanks all!

Thanks council, I'll prepare a longer message regarding GC1 removal and self-pinging.

Tobias: Concerning the compliance suite, is it now going directly into Draft or first a LC?

first LC

jcbrand: LC

thanks