XMPP Council - 2017-01-18

Hmm, I will be on a coach today during the meeting, I don’t know if they have wifi there so I might be unable to join. :/

Link Mauve, thanks for letting us now :)

Link Mauve, https://www.youtube.com/watch?v=TiBI3A2WcrE

I wont be able to attend either.

seems it's about time

1) Roll call

Link Mauve and daniel sent apologies earlier today

Dave Cridland?

.

Hiya

2) Minute Taker

happy to do it if nobody else wants

I'll do it

ok

3) Move XEP-0153: vCard-Based Avatars to "Obsolete"

seems the discussion pretty much died

but hey..let's vote anyway

-1

+1

I think there's no concensus to do this, so -1.

Ugh. Consensus.

Actually I don't even know how to spell anything at all today.

'anything'

Dave Cridland: Not to worry, that's me every day :)

the rest will vote on list, if they want to i assume

What about the 'at all'? See? Fraught with complexity.

4) XEP-0300 fixing, and Jingle FT

according to latest news, Swift does Jingle FT :4 with base64 and Salut-a-toi does Jingle FT :4 with hex encoding

everyone in agreement that bumping versions, fixing examples and explitly specifing what encoding to use is the right way to go from here?

Which namespaces are getting bumped?

Jingle FT *and* hashes?

Jingle FT and hashes, yes

+1 for namespace bump and specifying an encoding

Does Jingle FT need it? I thought bumping hashes would be sufficient?

Dave Cridland, that was my understanding too.

Kev suggested this would be neede

*needed

I found some wifi at the first stop, but no wifi in the coach itself. :(

You'd have to bump the version that Jingle FT used for hashes, wouldn't that break Jingle FT compatibility if two things were advertising ft:4 but using different hashes versions?

So I think that means you'd have to bump FT too

What Sam said.

Unless he and I have both misunderstood Jingle FT.

Does Jingle FT mandate hashes? I thought they were optional.

"REQUIRED when offering a file, otherwise OPTIONAL"

Kev, although XEP-0300 version is discoverable via caps, so clients could send the version the other side supports

Ah, no, REQUIRED when offering.

Also, it requires a specific namespace.

So yeah, bump away.

Indeed, then +1 to bumping both.

ok..great

5) Sam's elaborate topic "A bit late, but let's have a vote on moving the 2016 compliance suite forwards. Even if we get vetoes or people think it doesn't make sense, that will give me a place to start on changes to the 2017 ones."

i think it'd make more sense to ship out a compliance suite XEP for 2017 at this point

heh, sorry, that description got a bit out of hand

In that case, what differences should there be for 2017?

Um. I'll have to go on list for this. But I don't *think* 2016 is ready, quite, yet from what I recall.

SamWhited, my idle XEP..but yeah...i'll post more on the list

Sounds good; I'll start a list topic about what we want for a 2017 list then, and people can reply with fixes there.

Unless someones already done it or is drafting an email, in which case I'll wait for that

SamWhited, sounds like a plan

6) Accept https://xmpp.org/extensions/inbox/bind2.0.html as experimental

One more thing

before we move on

ok

On this topic: can we go ahead and deprecate the 2010 ones and just not have compliance suites for a bit? I still feel like it's confusing to have them hanging around when we have no new alternative and many of the things in them are probably out of date.

Especially if we're going to be starting over again on 2017 ones which will presumbaly take a while to get right.

Is no current compliance suite better than an out of date one?

I think so

SamWhited, probably makes sense...although i think we should have at least a new one before deprecating the old one

I think I'd want to review them again to understand why.

We've had a new one for a while, it just didn't get advanced. I suspect a new-new one would be the same way

If 2010 (or whatever it is) is up to date, I think it's fine, but otherwise I think it's better to have no recommendation than to have old ones that may be wrong

SamWhited, true...the 2016 is experimental, so fine my be deprecating the 2010 one

I don't think they're likely to be wrong. But in any case, I'll review and get back to you.

I wouldn't want someone to go implement, eg. SI file transfer or something if everything is moving to Jingle just because they saw it in an old document

Yah, if they're not wrong I suppose it's fine to leave them

I haven't actually looked; although it still looks bad that the current up to date recommendations are from 2010

Might be better to deprecate just for image

SamWhited, any other points on that topic?

Nope, that's it. Thanks.

6) Accept https://xmpp.org/extensions/inbox/bind2.0.html as experimental

"I wouldn't want someone to go implement, eg. SI file transfer or something if everything is moving to Jingle just because they saw it in an old document" Sounds sound to me, FWIW.

(note that I'm not sure that SI File Transfer is in there; that was just the first thing that was sort of superseded that came to mind)

+1 to accept bind 2.0

+1 on Bind 2.0.

SamWhited, It isn't.

+1, although it's missing tons of specific references to the standards and extensions it talks about

SamWhited, The only "old" thing is Privacy Lists.

Dave Cridland: I definitely think we should deprecate it then

SamWhited, Only applies to Advanced Server, actually.

7) Deferring lots of XEPs

SamWhited, why did you put that on the agenda?

Just wanted to mention that I'd done this in the notes (in case it wasn't obvious)

Tobias, I think he likes deferring things and has run out?

If you notice anything wrong, or want to push something forward please do so

I do like deferring things :)

we used to have a calendar that had the dates in for when XEPs expire or are deferred

but people thought we needed a new website instead :P

Zash suggested a bot that deferred things automtaically; I doubt anyone has the bandwidth, but I liked the idea

ok..guess that's noted then

8) Consider advancing XEP-0333: Chat Markers to LC

Related; this is the only deferred thing that stood out to me as in wide spread use (I think?) and that hasn't been changed because it appears to be working.

is it in wide spread use?

Is it in widespread use? :)

I thought so? Conversations does it anyways, and I tend to see it for all my contacts (only a few of which use Conversations), but I don't have a lits.

Is it in... Oh, wait.

Maybe no action is necessary

LC it. If it's good enough to implement, and seems to be working, it's probably ready for a Last Call.

And if nobody responds and/or people flag issues, then that was what LC was for.

happy to LC it , yes

In particular, "widespread use" is for Draft->Final, really, not Experimental->Draft.

Might be worth LCing 233 while we're at it.

Kev, Hmmm. Why is Mili's name not on that? She wrote/rewrote quite a chunk of that, didn't she?

happy to have an LC on that too

Happy to LC it, mind. Just glanced at it and was surprised.

9) Date of next

same time next week?

Cool, I'll issue LCs on both of those then.

WFM

wfm

Tobias, WFM, noting that I'll be travelling the week after.

10) AOB (probably none because of all the discussions in between)

no AOB it seems, YAY

thanks everyone

Thanks all!

SamWhited, thanks for wrtiting up the minutes

sure thing; sent

actually, how does LC work? I guess that needs to be pending votes too

Or would the absentees just vote on the LC itself?

Or do they vote after the LC?

Process is hard.

To the XEP 1 machine!

"Before an Experimental XEP may be proposed to the XMPP Council for advancement to Draft (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs), the XMPP Council must agree that the XEP is ready to be considered for advancement. Once the Council so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental to Proposed and (2) issue a Last Call for open discussion on the Standards list. The Last Call shall expire not less than fourteen (14) days after the date of issue."

"Once the council agrees", so I guess that needs a vote

SamWhited, we first vote on it (probably the safest to show we're all in agreement)

Fixed; marking us all as +1

SamWhited, so...let's vote on it next week?

Oh, or that; I'm doubly getting ahead of myself

or do the minutes include a record for voting so others know they'll have to vote on it

otherwise it'll look a bit odd

> Kev, Hmmm. Why is Mili's name not on that? She wrote/rewrote quite a chunk of that, didn't she? Probably because adding oneself to the author list is unseemly, and no-one else did it.

It says that we all agreed

considering how long they were ignored one week more or less probably doesn't matter

yah, WFM