TobiasSamWhited, daniel, Dave Cridland, Link Mauve, ping
SamWhitedI am partially here and will be fully here in a few minutes
Dave CridlandTobias: ?
TobiasDave Cridland, wanted to know whether you are there, for the roll call
Tobias2) Minute Taker
Link MauveHi, I’m here too.
danieli can do it
Tobiasjcbrand, or are you available for it?
jcbrandYes, I'm available
jcbrandTobias, daniel ^
Tobias3) Vote on accepting "Consistent Color Generation" as Experimental XEP
TobiasI'll vote on list
Tobias4) Vote on accepting "Jingle Encrypted Transports" as Experimental XEP
TobiasI'll vote on list
SamWhitedI 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?
Link Mauve3) +1
jonaswSamWhited, from my understanding on the mailing list, vanitasvitae said he’d add more XEPs specifying how to use the JET framework with OMEMO etc.
Link Mauve4) I’ll vote on list.
Link Mauve(I haven’t read it yet.)
Link Mauve(The new version.)
jonasw(but don’t take only my word for it)
SamWhitedI'll just be on list then and ask first
SamWhitedor double check the discussion
Tobias5) Discuss removal of Groupchat 1.0 protocol from XEP-0045 ( request by jonasw )
jonaswI was only proxying that request
Dave Cridlandhas left
jonaswthe original request is from a discussion in the xsf@ MUC, I think dwd was present
jonaswand maybe SAm
jonaswbut I can give some details if needed ( Ge0rG can too if he’s around)
danieljonasw: please do. I don't know what this is about
jonaswokay, will do
jonaswthe 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)
jonasw(no reasonable way that is)
jonaswthen there was the suggestion to simply send presence to ensure that one is still joined
jonaswthe issue with that is that it could be interpreted as a Groupchat 1.0 join, which would not be desired
jonaswfrom this originated the suggestion to remove that Groupchat 1.0 protocol entirely
jonaswwhich would have the advantage that clients are safe against accidental Groupchat 1.0 joins when they desync
Tobiasä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?
jonaswthat’s mostly it I think
peterAre there still clients that support "groupchat 1.0"?
jonaswthe argument was that Groupchat 1.0 does *most likely* not exist anymore anyways
SamWhitedPersonally, I'm fine breaking compatibility with any clients that still support groupchat 1.0.
Kevpeter: Yes, implicitly.
peternods to Kev
KevBecause the fact that a presence chengae will cause a rejoin after an S2S blip is remarkably useful
danielgroupchat 1.0 join is a presence without the <x/>?
KevIf you removed that, suddenly lots of people wouldn't be in MUCs when they thought they were.
jonaswKev, is it? I think it’s not useful
jonaswyou’d want to specify the needed history instead
KevAnyway, this is a hack.
KevIf you want to change xep45 to allow you to know if you're in the room, add an iq to that effect.
jonaswgetting a proper error back and then making a proper join with history etc. sounds more reasonable
jonaswKev, that was also discussed, but is a separate topic
KevRemoving legacy joins is very much the wrong option here, I think.
Tobiasalright..do we want to continue that discussion on standard ML?
SamWhitedThat sounds sensible.
KevThat'd be the appropriate place, I think.
peterFWIW I agree with Kev.
Tobias6) Consider advancing XEP-0387: XMPP Compliance Suites 2017 to Draft (added by SamWhited )
TobiasSounds sensible to me, i think we should issue a LC if other draft requirements are met
danielnot sure if this is a blocker but the xmpp compliance suite requires the bookmark xep which can't be implemented right now
SamWhitedI 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
SamWhiteddaniel: bookmark can't be implemented?
danielbecause it depends on pep functionality that doesn't exist
danieland which people don't want to have in pep
danielbut it's fine with me if we start a last call on xep387
danieli can bring this up in the last call
Link Mauvedaniel, it could depend on the previous version, which was using 0049.
Link MauveWhich is AFAIK how every client implements it.
SamWhitedSounds 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.
Ge0rGCan we get MIX out of 387, then?
Tobiassound sensible then
Tobiasso we're all in favour of issuing a LC?
SamWhitedMIX has been out of it for a long time (and I still think that was a bad decision, but I did it)
Link MauveSamWhited, also, why are the compliance suites standards tracks, instead of informational?
Ge0rGSamWhited: ah, thanks. Didn't get that update.
SamWhitedLink Mauve: I'm not sure, they include 2119 language?
SamWhitedAnyways, +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
Tobias7) Issue a new LC for XEP-0352: Client State Indication , based on https://github.com/xsf/xeps/pull/427
Tobiasany objections to this?
SamWhited+1 for LC
Tobiasi'm also +1
Tobiasalright. Let's come to an end as we're already exceeding half an hour.
Tobias8) Date of next
TobiasSame time next week?
Link MauveI won’t be here next week, I’m on vacations.
TobiasLink Mauve, happy to vote on list?
Link MauveSure. :)
SamWhitedNone from me
Tobiasbangs the gavel
SamWhitedGood stuff; thanks all!
Ge0rGThanks council, I'll prepare a longer message regarding GC1 removal and self-pinging.
jcbrandTobias: Concerning the compliance suite, is it now going directly into Draft or first a LC?