XMPP Council - 2019-06-12

...?

Where's the meeting start klaxon?

Ooops.

1) Role Call

.

Cool. Quorum achieved.

cluster ready to operate

I'm here

Great.

2) Agenda Bashing

Anything I missed?

If not:

I might go missing silently in the middle of things

how should we know?

3) Items for voting: a) Last Call: XEP-0280 (Message Carbons)

I want to bash agenda item 3a

oh wow, *now* a bunch of mails show up in the standards folder in my MUA. disrgeard my earlier question.

I'm happy to shepherd this one through if nobody else particularly wants to.

But overall, I think it's ready to be Last Called.

I’m +1 on the LC

I agree with the LC, but I'm not yet convinced it's ready to advance

and I’m also fine with dwd shepherding it

Yay?

I'll need to properly return before I can write that down though

Kev, ?

[+-][01] ✏

I'm not convinced an LC when Ge0rG isn't convinced it should advance is productive

because we'll probably bore people of LCs on it.

But I won't block progress, so +-0.

Kev: that's the exact definition of last call, isn't it?

Ge0rG: Depends, I read your 'not convinced' as 'well, we can ask, but I'd -1 advancing it without changes'.

Ge0rG, boring people?

If that wasn't the spirit it was intended...

Well, if Ge0rG would definitely reject the advance, it's a good reason not to bother. But if we can get some feedback on it (from Ge0rG or elsewhere) that will get it across the line, it feels worthwhile.

We've been through a bunch already, and I need to check my own feedback from them for whether everything was included

so you’d re-submit your earlier feedback for inclusion?

jonas’: most probably, yes. The last times after LC, just nothing happened

My preference, despite me not blocking an LC, would be to wait until we're fairly convinced the house is in order before doing another LC.

Ge0rG, I suppose the interesting question is do you feel confident we can get it to Draft this time?

I'm also convinced we need to copy all message errors to all resources

I tend to agree with Kev

dwd: I'd Rath first await implementation experience from the new changes

*rather

I haven't heard of any server implementing the new namespaced copying rules

Ge0rG, That's true. But we don't require that for Draft.

Maybe an LC will make the developers realize there was a change.

Ge0rG: Incidentally, we re-implemented Carbons the other day, and I *think* we follow all the rules in the XEP. But that's not deployed anywhere.

Kev: this is getting philosophical

implementation experience would be neat, but is technically not a requirement for Draft

Ge0rG, But still, I'm OK with rejecting a LC on this, but I'd like to do so in such a way that encourages it to happen some day.

jonas’: Given that we have huge amounts of implementation experience of everything other than the current version, Drafting while the current version doesn't have that seems...odd.

I don't want to end up with a useless Draft that needs undocumented knowledge to follow properly

And what Ge0rG says.

OK, well, in that case we should be pushing server implementors to implement it and/or feedback on why not.

maybe we can encourage or invest in the existing implementations to upgrade?

Kev: you could write about your experience on list and encourage others with the new namespace carrot

Ge0rG: Maybe I could.

OK - so the consensus is to reject for now.

yes

b) Last Call: XEP-0300 (Crypto hashes)

+1 on that one

Technically, this one has authors that are presumably active, given one of them is in this meeting, but Jonas has offered to shepherd it through if they're busy.

May as well.

(+1)

I'm +1 on this.

Didn't we move the actual hash algorithm list into its own informational XEP?

yes

Oh, except no.

The published 300 still has them in.

yeah

someone hasn’t merged it yet

There are still hashes named in 0300.

Ah. Poke the editors? :)

an editor shall do that before issuing the LC

What a disgraceful someone.

an editor will

But yes, merge and Last Call.

Seems weird to issue an LC on an unpublished version, but I should be used to weird by now :)

Do we have a rendered version of the proper content?

Kev, You're welcome to insist on a publication first, of course.

I'm pretty sure I'm +1, but I'd like to have a quick glance to reconfirm

Ge0rG, Then be -1. Seems perfectly sensible.

I can probably scp one without css somewhere

but nobody will get hurt by delaying 1w

Alright, I'll be -1 then

Cool.

4) Outstanding Votes

I don't think we have any.

5) Next Meeting

+1W OK for everyone?

+2W for me

Anyone else can't make it next week?

+1wfm

OK.

6) AOB

Anyone?

I noted in xsf@ that '357 looked enticing for a Last Call, but I vaguely recall Kev was going to do some edits at some point.

I think discussing those might mean Guus comes out with other comments, given he implemented it recently.

I think 357 needs a chunk of love before it's ready for advancement, yes. Sadly, I've not actually got as far as doing the implementation that I was expecting to lead to those changes yet.

I wonder at this point how bad it would be to advance 357 with the intention of replacing it later, instead of waiting for a better version.

entirely replacing it?

Kev, You in a position to shepherd it through? I think it's got some implementation at least, now.

I guess we'll find out if it goes to LC. I'll ask for help if I fail.

OK - shall we put it on the slate for an LC next meeting?

Hi, sorry I was talking with pep. IRL, didn’t see the time. ;_;

Vote on having a vote to LC for having a vote on advancement? How meta.

Oops, sorry

I’ll read the minutes and take part on list.

Kev, Yeah. I'll just do that.

Link Mauve, You're lucky - both items for a vote are being dropped by consensus anyway.

Anyone anything else for AOB?

not me

Please no.

Excellent.

7) Ite, Meeting Est

Thanks all.

Kev, Dunno why you're complaining, we're a minute short.

Kev, there's some confusion on what could/should be added to 357. I've talked to Daniel, who is under the impression that 'implementation guidelines' are deliberately not put in - while we both agreed that they'd be handy (with regards to when a server should trigger notifications, specifically).

thanks dwd

And started a couple of minutes late?!

I was just thinking of an AOB to cover at least 10 minutes

if anything, I'd like something like that to be added.

as long as those are mostly guidelines and not mandatory parts of the specs…

Now where did I write about 0357 not being ready yet?

I don't immediately see a reason for them to be mandatory - but triggering a notification 'at the right time' quickly gets complex, and might even vary between platforms. Some kind of documentation around what is a sensible approach would be welcome.

Ge0rG probably somewhere just above where Dave awakened me from my slumber. 🙂

Others refer to me as 'he-who-shall-not-be-named' to avoid this issue.

move this to xsf@?

It's the same situation as with CSI and I understand why CSI has deliberately none. I wonder if we shouldn't just put up wiki pages and have the XEPs link to it

Are these network protocols or software specifications?

Zash: do we want them to work properly for our user base or do we want to differentiate by features?

> I wonder if we shouldn't just put up wiki pages and have the XEPs link to it +1 if it's about xep remarks

https://twitter.com/jutta_steiner/status/1138815580184731650 looks like we can close the XSF Council now.