XMPP Council - 2018-01-10

https://xmpp.org/extensions/inbox/client-key.html would probably benefit from renaming as well.

Naming things

Like user-invite?

Kev, Renaming?

I would expect a client to submit an automatically generated name for themselves in most instances, but have the user able to rename things in the event that they have, for example, two devices with Swift for iOS on.

That's how these things have typically worked in my limited experience.

Last-used is also useful in these instances.

Kev: oh, renaming the client name.

It might also make sense to differentiate long-term CLIENT-KEYs from short-term ones for resumption.

It will be very confusing if a client name is present twice, with different keys, one for 24h and another for 30d.

If you read the proto-XEP in an unfortunate scrolling position, §3.2 reads like "Kev Revocation"

You can revoke Kev, but he has a TTL as well, as do we all.

Are we sitting comfortably?

Yes, sir!

Then let's begin.

Kev, Glad someone got that. :-)

1) Role Call - Who's here?

I seem to be.

here

SamWhited, ?

still here

Green-ness from SamWhited but no response, so I'll assume absence for now.

We'll move on...

2) Agenda

As emailed, but we have one additional ProtoXEP to consider.

I suggest we don't, actually.

here now, sorry about that

As far as I can tell from the rules, I should open that vote now, but I'm happy to defer it if we think we ought to?

In as much as if we want to encourage people to be voting in meeting, rather than onlist (and I think we do), slipping things into the agenda without notice is counter to that.

Dave: you skipped the initial #2 from your agenda email.

Ge0rG, I'm renumbering, sorry.

I have no strong opinions on hurrying my and MArc's protoXEP. It wasn't even yet officially announced to the ML.

Kev, If everyone's happy with that, we can push it off until next week.

(it will be once the mailman passes my mail through; I sent it just now)

Ge0rG, Oh, in which case it's missed this meeting, so perfect.

(When I'll probably be on the road and will have to onlist anyway, unhelpfully)

So, moving on.

3) Did everyone have a nice Christmas?

So, long story...

But for the sake of brevity, yes thank you.

Yes, without further detail.

On list.

4) ProtoXEP: PEP Avatar to vCard conversion.

ahem, I mean, "yes, thank you"

https://xmpp.org/extensions/inbox/pep-vcard-conversion.html

Kev, Thanks.

on list

I've got a few quibbles with this that I'll try to send out on standards@, but nothing to block publication.

+1

(+1)

+1

+1 from me.

I read that as everyone +1, and an on list from Ge0rG.

Yes.

5) Client Key Support: https://xmpp.org/extensions/inbox/client-key.html

I'm obviously +1.

Could do with some extra stuff, I think, mentioned earlier, but good for publication. +1

+1, even though we need to put some more thought into the network-interruption-during-auth issue.

+1

daniel, ?

on list

Thanks.

6) TOTP 2FA - https://xmpp.org/extensions/inbox/totp-2fa.html

+1

on list.

on list as well

+1 from me too.

on list

I do think client-key needs examples of it being used.

Kev: examples in the XEP text?

Yes.

Kev, Yeah, I agree. Needs examples in the I-D too.

Kev, Same with TOTP.

7) Deprecate XEP-0126: Invisibility

What was the background to this proposal?

(I'm almost certainly +1, but just for flavour...)

I'm +1 for this, we should be advising people to do invisibility via Privacy Lists anymore.

Insert negation of choice.

Kev, I assumed this was SamWhited's general push toward deprecating old stuff.

Kev, And yes. Shouldn't be advising.

Yah, background is that privacy lists are deprecated and there are multiple ways to do invisibility which is confusing (I had this specifically brought up at a meetup by some random people)

+1

+1

What is the encouraged way to do invisibility?

Ge0rG: With a cloak from Hogwarts.

Ge0rG, XEP-0186 from memory. I may have the number wrong, but it's somewhere around there.

+1

Kev: that can be circumvented with the Marauder's Map.

Ge0rG: https://xmpp.org/extensions/xep-0186.html

https://xmpp.org/extensions/xep-0186.html

Kev, Did I mention that Hogwart's is being closed? Or at least, the Great Hall part of it?

But anyway.

I see a +1 from everyone except Ge0rG.

I suppose this is an "on list" from me then, I don't want to rush things without skimming through both XEPs

8) Trello Tidy

A few things in Trello I'm not clear about the status of:

BTW, who is taking notes?

a) There's a bunch of stuff in Pending that I think has expired and/or been voted on.

Ge0rG, Yeah, nobody volunteered so I'll write something up later.

Dave: thanks

Are pep-vcard-conversion and "Deprecating 84" in conflict?

Yes, but even if we decide to deprecate one of the avatar formats I don't think it hurts to have the informational work around available for a while

In particular, I think we were bound by rules to repeat the Last Call for XEP-0387, but I don't see that as having happened.

But also, people have continued commenting on the previous Last Call thread.

I am not interested in addressing feedback that came in after the last call was over. Forcing it to be restarted and never getting this out the door is starting to drive me mad. Feedback will be addressed in a future version (lots of it is very good), but not in this one unless someone else wants to take over.

The Last-but-one Call?

SamWhited, I'm fine with that.

SamWhited, I'm just trying to figure out if we can actually vote it through at this point.

According to my mail log, the last Last Call was going from December 7th to December 21st, and there was no feedback after December 11th.

Ge0rG, I can't find that Last Call announced on the mailing list, which is my problem. Was it?

Oh, wait, yes it was.

Title changed, of course.

Dave: https://mail.jabber.org/pipermail/standards/2017-December/034019.html

So yes, we *can* vote on this (and I should have put it on the agenda, sorry)

So while the discussion was under the Last-but-one Call email thread, I don't think the content should be ignored.

We can vote, but I don't think the feedback there has been incorporated as of yet.

It will be incorporated in the 2019 suites since it came in after the LC had ended.

https://mail.jabber.org/pipermail/standards/2017-December/034019.html - that last call?

SamWhited: are you speaking of the October LC?

SamWhited, No, looks like there was a Last Call open at the time.

I don't recall. I'm reasonably sure I had all feedback addressed, then the council changed before the voting was finished and now we have another LC and more feedback.

SamWhited, Sounds about right. Can you incorporate that feedback and we'll vote (and hopfully publish) next week?

I think that flow of events is correct, but the implication that the more recent feedback doesn't need addressing doesn't seem right to me.

No, I would like us to vote on the current form. We can address anything else remaining in next years.

That seems to be a sake of process for the sake of process.

SamWhited: are you going to keep a list of open feedback items for next year's Compliance Suite?

I disagree, restarting the LC seems to be process for the sake of process

I just want compliance suites to actually exist in the year that is in the title.

I don't know, without re-reading the whole thread and the XEP, which feedback is still pending and needs to be carried over into 2019.

I mean issuing a vote when you already know that one of Council has outstanding feedback that isn't getting addressed seems to be a redundant action.

If I issue a PR to address my feedback, does that make this any easier?

Not that I have any spare cycles.

No, it doesn't, the point is to not go through multiple more weeks with multiple more changes which will just lead to more people having disagreements and more revisions. At some point we just have to say "this is good enough for this year". That *should* have happened before this year started, and it was on track to, then an excuse was made to continue putting it off and submit feedback late.

The way I see this, me being on Council requires me to do a thorough review of it before advancement. I did that, and found stuff that needs addressing. Whether that was given during the renewed LC, or at vote time, doesn't change that. But doing it during LC gives the opportunity to address it before the vote.

SamWhited, Yes, we do have to decide when to say it's good enough. And it's Council that does that, via the process in XEP-0001. I don't think ignoring feedback is a solution here.

ANyway, we're running out of time, so I'll move on for now.

Kev: if your feedback is not incorporated before the vote, does that imply a -1?

I think we'll skip to:

Ge0rG: Well, yes. Unless the discussion leads to my feedback being wrong-or-such.

9) AOB

Maybe we can arrange for a vote of the XEP as-is, _now_, and have Kev make the PR and Sam start a "Compliance Suite 2019" with the feedback incorporated in the next weeks?

No real AOB here. I'll send out a request for agenda for the Summit shortly, but nothing much for Council to do about that.

We've had a Council re-election and holiday season block progress for some time already.

AOB: publish-options

can we vote on one of the PRs

preferably the latest one

daniel, We can; I saw these were voted on, but the vote was deferred for more feedback from the list - but I didn't see any discussion there.

daniel: IIRC you wanted to ask for comments from the community?

As I lack experience with pubsub and understanding of the complexities of 0060, I'd like to hear from parties implementing this and/or impacted by the change.

Ge0rG, i wanted to ask for comments? i already did. that was mostly ignored. so i assume people either don't care or it's 'above their heads'/the don't have an opinion on that

not sure how waiting longer or bumping the thread will be any help

at some point council will have to make a decision

as you can't force 'the community' to have an opinion on that

daniel, OK, but the vote was explicitly deferred in order to gain feedback. Hence I didn't put it on this week's agenda.

I don't know of PubSub implementations outside of the ones represented by xsf@ lurkers.

Dave, how would you like me to gather feedback then?

daniel, If you're asking for a vote in the absence of community feedback, I think I'd want to vote on-list to find the time to really study these in any case.

daniel, I'm not - I wasn't in that meeting. I'm just going by the decision made in my absence. Let's vote on this next week, feedback or not.

Do we have council members who are working on affected implementations, besides of daniel?

I think anything in AOB that's going to need Council to do reading to get context in their heads is going to result on on-list at best, so may as well be a formal item in the following meeting. But I can onlist.

Ge0rG: All pubsub implementations are affected, I think. So yes.

Kev: it would be great to have feedback from those Council members, then. On list.

Dave, i'm more than fine with council members taking their time. i just want them to take that time and not prolong this for ages

I'm all for voting on list, this meeting or next. I don't think we're going to get any community feedback on this as XEP-0060 is just too complicated and very few people understand it and even fewer have implemented it.

or come up with a strategy to gather feedback from people who work with pubsub

daniel, It'll be on next week. That's the first of the XEP-0060 trello cards, is it?

ok

So:

If someone starts a thread, or bumps the current thread, asking for feedback, I'll give mine there. Then maybe that will encourage others to give feedback on standards@. Or maybe it won't, but it's a chance.

10) Next meeting

Same time next week?

+1W WFM

I can't do next week, but enjoy yourselves without me.

WFM

Kev has given apologies already, anyone else?

I'll take that as a no.

So I think we're done.

11) Ite, Meeting Est.

Now I can go write the minutes.

Thanks all.

So, RE Compliance Suites: I think it is important to work to a deadline on these. The beginning of the year may be an arbitrary deadline, but if we're going to consistently issue guidelines we can't keep doing a repeat of the 2010 or 2012 ones where they end up being in experimental for 5 years (or even half of a year). This is not a normal XEP where we can never make changes again after final and once the community adopts it it's hard to change, we have another shot every year. I hope that clarifies my position a bit.

If a council member thinks that it would be harmful to issue these as guidelines, they can of course -1 but I don't think any of the problems with it are that serious.

I think missing things out, or recommending the 'wrong' thing (e.g. '84 instead of '153, not doing '49/'54) can be actively harmful for interop, as we expect new implementations to use these specs as a 'what do I need to implement at the moment', which is why I care. You've noted before that it's confusing when there are multiple options on the table and people don't know which to choose. If we point people in the wrong direction for the current reality with the compliance suites, that's adding to the confusion.

It's not the same as having some nice feature that we could include, but don't, for things like that, in my view.

I think the argument was that the compliance suites should posit how things *should* be, not how they currently are?

Isn't it somewhere in between? What is needed for interop, and what is needed for a nice future?

How far ahead? The 153/84 thing isn't clear at all. '49 has been the status quo for a decade and a half, and shows no signs of changing, etc.

Then that feedback should have been sent when it was in LC

If we have compliance suites where implementing the suggestions means that you can't interoperate with the same features as everyone else does them, that seems deeply unhelpful unless we're very clear that it's aspirational.

SamWhited: There's two things with that. 1) There has been a new LC, triggered by the change of Council, since. 2) Council's review on advancement is not the same as LC feedback from the public.

1 is process for processes sake and I don't think ever should have happened

2 I disagree, council should have gotten their feedback in before it came to them for a vote so that it could have been addressed

I wasn't Council for the previous LC, and it hasn't been voted yet. Which is one of the reasons for (1).

If there is disagreement and it's not addressed they are obviously free to -1, but we should still get feedback to the author in a timely manner instead of giving it when we -1

I don't see why your feedback would change because you are or are not council

Did you do the same level of review of all XEPs going through the process before you were on Council, honestly?

I suppose that's fair; if I reviewed them at all I gave the same amount, but I didn't review all of them before I was council.

The level of review expected by Council is not the same as that expected from every other person in the community. ✏

The reason I took a break from Council, as it happens, was purely because I couldn't afford to spend the many hours every week it often takes me to be on Council.

Either way, this is about deadlines and I think we should have made the deadline and should still get these out as quickly as possible even if they're not perfect. I don't see any major problems with them as they are now (for compatibility or otherwise) so I would like to have it voted on. If it's -1ed because someone disagrees then so be it.

(FWIW, this was the final argument which convinced me to issue the LC, I didn’t do that for process’ sake)

So how can we move on from here?

If this had made it through previous Council, this wouldn't have come up, but as things stand, the XEP is in front of me and as Council I do have to make the vote I think is appropriate - and I do think some of the recommendations in there will add to confusion and therefore be potentially harmful.

I have offered to propose the changes I think are needed myself, to try to unstall this, but I can't force that.

More harmful than continuing to not have compliance suites even though we could immediately fix them in the experimental suites for next year?

(I really don't want to, because I'm time-poor, but I will).

We could immediately fix them in the suites for this year, and have them advanced, too.

The time to write the changes for the current text is presumably shorter than to write a new protoXEP, and we've not voted on either yet.

But that will take multiple more weeks and I think it's much more important to have compliance suites issued in a timely manner.

Does it need to?

It would be uncomfortable for me to fit submitting a patch in before next meeting, but I will if that's the only way to unstick this.

FWIW, there’s no need for a new LC if changes are incorporated

Vote happens next Wednesday. Everyone other than me votes in meeting. I vote onlist at the start of the following week. 12 days and it's done.

jonasw: I know.

if I’m reading XEP-0001 correctly

I’m not sure that SamWhited knows.

I am aware

so I don’t see how this will take weeks.

update today, vote next week, 1w exactly, done.

I am just sick to death of us having to have everything be perfect and not being able to meet a simple deadline.

As soon as there are new changes there will be someone else mad about it and we'll bike shed for another month. I hope to be proven wrong on that, of course.

I think the only deadline is actually the Author having addressed feedback before Council votes on it ;)

SamWhited, no, they won’t be asked

And that was done, then the council didn't vote for weeks and made up an excuse to put it back into LC again.

well, okay, they will be asked implicitly, but I doubt that there will be much going on w.r.t. to that.

I think you're wrongly fixating on LC here.

The only thing the LC has meant is that my feedback went to list as LC feedback, rather than as justification for -1.

as an aside I think SamWhited is right, for instance the new https://dino.im/ website advertises "compliant with the official XMPP Compliance Suites 2016." and to someone not deeply involved in XSF that looks like it's 2 years out-dated

With the LC over, one way or another, Council are the only ones who are allowed (and required) to provide feedback now.

In both cases the Author's expected to address it to the satisfaction of Council.

Ge0rG: Well, that's not true. Anyone is allowed to provide feedback at any time.

Kev: damn.

LC is a request for a specific type of feedback, at a specific time. But standards@ is not muted the rest of the time.

but council does not need to issue a new LC

council is free to advance a XEP in its current state, no matter which pending feedback there is

It was addressed to the satisfaction of council as far as I understood it, then the goalposts shifted and here we are over a week into 2018 and we still only have 2016 compliance suites.

If it was addressed to the satisfaction of old Council, surely it would have been advanced by now?

But regardless, current state is, I think:

One would think. These are also the same compliance suites that should have been 2017 ones but we kept bikeshedding details until eventually I just renamed them 2018.

Sam wants a compliance suite 2018 to be advanced.

Kev wants changes made to compliance suites 2018. Kev wants compliance suites 2018 advanced.

OK. So old Council failed. That can be a thing.

New Council are here, and there is a clear path to how to get this advanced imminently.

I don't currently understanding why you don't want to take it.

I also don't English, obviously.

If it's that you think the changes I'm proposing are actively wrong, I don't think that was reflected in your replies to date.

We should have voted weeks ago, we should have voted this week, etc. every time there is some excuse why we should vote later. More changes will just lead to more delays.

But I do think the feedback was good, FWIW, just not worth spending more time on until next years.

I don't think it was on Dave's agenda for voting this week.

There has been a card on trello for months asking for a vote.

SamWhited, do you really think that people are actively making up excuses to sabotage the compliance suites from being published? ✏

jonasw: not in a malicious way, but yes

I get, I totally get, the frustration in this dragging on. But I'm offering an out here by doing the work needed to get this through.

what is a non-malicious way of doing that?

And entirely not because I love doing XEP work.

So, separating 'how we got here' from 'where we go next', I'm not currently clear why you would rather it go to vote next week in a form it'll be rejected, rather than go to vote next week in a form I have no reason to anticipate won't be accepted.

Kev, if you can summarize in two sentences what changes you want, I’ll make a PR for you.

jonasw: Thanks. I think at the point I've trawled my previous comments and got it down to two sentences, I may as well submit the PR, but I very much appreciate the sentiment.

k

(just got pulled into an actual work meeting, sorry, maybe be unresponsive for an hour or so)

https://github.com/xsf/xeps/pull/554 seems to be stuck in limbo, after we agreed on needing it in Council last year. I think that needs a Council vote too.

Kev: thanks

I have submitted a PR that addresses my feedback, and which I will happily +1 if merged.

https://github.com/xsf/xeps/pull/569

From the PR message:

This addresses, I believe, all the issues I raised. Where I was wrong (84), or it was contentious (220), I've dropped the point. Where Sam felt it was worth watering down (needing 153, but only read-only), I've done so.

If other Council folks would be kind enough to review this and check if I've screwed anything up, or this would alter their +1 of the spec, please let me know early. Ideally before Sam reviews it, to make this painless for him.

Assuming this gets merged in time, I suggest a vote on advancement next week.

daniel, Ge0rG, Dave: ^

I will be mostly out of action between morning Friday and next meeting, so if people have things I need to address, please let me know by then.

Damn. Reading those diffs is really a painful excercise in following up indirections.

We should add aliases &yes; and &no; for the #1000x codes

The what

So ✓ is "yes" and ✕ is "no", and you need to know the order of the columns from elsewhere in the document

Kev: so you've added 223 to the "IM / Advanced Server" profile, but not 222.

How was it you fetched PRs from git?

Ge0rG: if you know XML-y things I would love suggestions on how to fix that… I constantly put things in the wrong place because I couldn't remember what the number of each one was.

Zash: `git fetch <remote> pull/25/head:<localname>`

Although, it's always UTF-8 encoded no? Maybe I just don't need to escape them… not sure why I didn't think of that before, I should try that.

SamWhited: might be as easy as this: `<!ENTITY yes "&#10003;">`

oh, that's a good idea too…

Thanks, I'll update that in next years.

SamWhited: great!

SamWhited: I hope you keep track of the pending changes for 2019.

Kev: so you've added 223 to the "IM / Advanced Server" profile, but not 222. Yes, because 223 is needed for 48, but this might not be clear. It was already required, I just called it out.

Kev: 48 RECOMMENDs 223, but it does not REQUIRE it.

I still think it is good to call out support for 223, but then we should also add 222.

Anyway, I'm okay with any subset, including the empty one, of {222, 223} be part of CS2018.

Ge0rG: I'm trying to keep the diff as small as possible while addressing my comments. If you really want 222 if 223 is added, I'd be inclined to remove 223, but I think what I've got there is helpful.

Ok, thanks. In that case, I'd go with what's there.

I was pondering whether to have 223 as a client or not. I'm happy to make that change if people want.

Kev: my feeling tells me to replace the "N/A", but then again I haven't implemented PEP yet anyway.

ooi, why are the compliance suites dated by year, and not versioned? Is there a rationale somewhere?

I think that forces imaginary deadlines for no reason

pep.: so people see that this is recent and is actively being worked on

Come the year 2022 you have no idea whether version 3 of the compliance suite is still current or something that hasn't been worked on in years

I see your point, but I don't know if end-users need to know or care. I don't think they should even have to know about XMPP in the first place

Developers will know what version X of XEP-Y means

I wasn't talking about end users

And no developers don't know

Weren't compliance suites supposed to be for marketing or certification?

daniel, that is sad :/

Zash: they can if you want them to

I have a course you can let your employer pay for

But yes that makes sense for marketing etc.

That makes you a certified xmpp developer

You give them a medal? :P

Certificate

Same

People love certificates. HR loves certificates

Everyone has a masters degree these days. But a certificate will set you apart

I don't, and most at work here don't

Still I think we're doing ok

But yes sadly I get that's how it is

I'm positive it's not universal at all, but I've worked with 2 devs that had masters degrees and both were the worst devs I've ever worked with 😛

compared to the rest of the devs I work with with only bachelors degrees or no degrees

But in all seriousness: most normale developers (normal as in outside the xsf) believe xmpp an unnavigateable jungle of XEPs. Telling them here are the 8 xeps you should implement if you want your product to be compatible is really useful. And has nothing to do with just marketing

You can't assume that the average developer will know 400 xeps or do the research into what xeps are implemented by other clients

daniel, don't get me wrong, I also think compliance suites are useful ✏

I would hope developers would aim for some interoperability with other clients and servers

If their product is out in the open

but also used for marketing I think is good, but can also go wrong, dino.im mentions it's compliant with 2016 suites, which to everyone not in XSF makes it look 2 years behind

They could say "the latest compliance suite"

That already looks better

but then where would it link? and it might not always be true 🙂

Yes people have to keep up-to-date, it's a fact

They can change the text if it's not true anymore, or change the link to point to the newer version ✏

Or they can keep "2016" if they don't care about people thinking what you said above

Scrolling backwards a bit, I don't have a Masters. That makes me great, right?

No wizard hat?

I had a floppy hat, which is better.