XMPP Council - 2017-02-08

The council meeting will be at 1600Z as usual, correct? I think we never formally agreed on a time

right..the usual day in the week, the usual time

Link Mauve, thx for the votes

I really need to work out a way to do that in a more timely manner.

missing a vote from daniel, on "Advance XEP-0233 to Last Call ( http://logs.xmpp.org/council/2017-01-25/#16:07:14 )" in the "2017-01-25 Council Meeting Minutes" too

Tobias: if I do a +0 it will be advanced, right?

let me look up XEP-0001, one sec

I think it advances this afternoon anyway, as you'll have missed the two week window :)

But yes, majority +1 with no -1s will do it.

Which is what we have there.

A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the XEP to advance. A majority of Council members must vote +1 in order for a XEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.)

yes...0 or +1 will advance it to draft

XEP-0001 is far from being written in a straightforward fashion

Kev, i see 14 days limits for vote from ProtoXEP to experimental, and from LC to draft, but not for voting on whether or not to do an LC to draft :)

"(Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.)"

right...if it's the current council, we haven't set anything :P

Unless someone's changed those policies since they were set by Council in my time, they'll still be a 2-week voting period for everything Council does.

unless stating things at 4 places in the xep, maybe there should be a voting section that describes it for all voting cases, no matter if it's LC, or something else

Hi, I’m here.

let's see if that's still the case in 2 minutes

I think I’ll still be here.

I'm going to send out another request for a minutes taker to members@ now that we have some new members who may be willing

Just FYI

Ta.

ok..seeems it's about time

1) Roll call

here

o/

Here

Dave Cridland?

here

great..everybody there

2) Minute taker?

I can do it

great

3) Short update on XEP-0300 and Jingle File-Transfer

I've updated XEP-0300 and lance has updated Jingle File-Transfer to use it

jingle file-transfer namespace version got increased

We should also grep for every other XEP having copied this example and update them, I can send a PR doing that later.

Link Mauve, thanks

4) Voting to issue Last Call for XEP-0334: Message Processing Hints

i'm +1

+1

+1

+1

+1, I think.

great

4) Sam suggested advancing XEP-0186: Invisibility https://github.com/xsf/xeps/pull/385

if we issue a last call it'd require someone editing the feedback in, anybody here open to do that?

the original author does not seem to have time for that it appears

I would argue that if it takes a Council member to volunteer, it's not ready for Draft.

what Dave Cridland said

I brought it up because it seems to be widely used, but I also agree with Dave

Flag it on standards@?

Flag it?

It is worth noting that PSA was willing to make changes recently when it became deferred, so maybe he would be willing to see it through a LC?

you mean asking on standards ML if someone is open to taking over authorship? @dwd

oops, yah, probably should have said UTC

Tobias, Yes, I meant that.

Dave Cridland, alright...sounds sensible

so..no voting on issuing a LC for it

WFM

for now at least

5) Issuing another LC on XEP-0352: Chat State Indication discussion

it had an LC a bit more than a year ago, see https://mail.jabber.org/pipermail/standards/2015-September/thread.html#30326

* client state

*client, yes

it got updated based on the feedback and it seems it wasn't voted on advancing it back then....since another year went by, and the recent XEP-0198 stream management discussions i propose issuing another LC

What was the outcome?

does this sound sensible?

Oh, I see - so it ended up in limbo. OK - LC it again seems sensible.

I think this sounds sensible

if it got updated we should issue another LC

6) Vote on issuing Last Call on XEP-0352

+1

+1

+1

+1

+1

great

7) XEP-0280: Carbons being changed after LC feedback, reevaluate. see https://github.com/xsf/xeps/pull/382

it seems Last Call was 11 days ago, so there's still time for feedback to roll in

i propose voting on advancing it to draft next week

arg...11 days is wrong, had the wrong mail

the last last call was last year august

i mean august 2016 :)

i mean august 2015 :)

I think I moved that back to experimental, so the thing to do is reevaluate and issue a new LC if a vote never happened last time

SamWhited, do you want us to vote on issuing another LC this meeting?

I think it's ready for another if we want to try and move it forward, but I could go either way. I didn't add these because I especially want to LC them, it just seemed necessary to do something with them while I was cleaning up all the old LCs and should-have-been-deferreds

necessary to mention it, I mean.

ok

8) Vote on issuing Last Call on XEP-0280

will vote on list

I’m +1 on this one.

+1... Again...

+1

+1

9) Discussion on XEP-0302: Deferred vs. Obsolete?

https://github.com/xsf/xeps/pull/393#issuecomment-275883856

So it's Deferred now?

I'm not sure that I really care either way. As long as it doesn't show up in the list of XEPs by default or have shiny green "do this!" text on it.

currently, yes

We might make it obsolete and superseded by the 2016 ones just o have a nice cross-link if you stumble upon it in a Google search or something.

The author can move it to Retracted, and we can assign who that Author is.

As I explained during the Summit, we often have to tell people they should actually use deferred extensions, except for some actually obsolete ones. It would make sense to actually obsolete those which are obsolete.

I'd obsolete it, ideally with with SamWhited's new XEP says it supersedes it

Link Mauve, +1

Or we can bend rules and make it Obsolete.

I'm happy to claim authorship if psa doesn't mind (and retract it)

and also what Tobias said

Can we just have a general vote that all old compliance suites are superseded by the 2016 ones?

obsolete in principle is the right status. but we don't have to rush things

And then mark them all as obsolete / superseded?

(all old compliance suites that are not already marked as superseded by a newer one, that is)

https://github.com/xsf/xeps/pull/392 is also of interest, fyi.

SamWhited, there is just the one remaining, not? the other ones are already obsolete, not?

Tobias: That may be true, if we do a general vote and then I discover otherwise I won't feel bad just updating it without going through the process again though :)

So let's add in the superceded, which seems obvious and an Editor task, and I'm fine with Obsolete if that works, even if it's bending rules somewhat.

but let's try to vote on obosoleting the old ones, and marking them superseded by the 2017 one

or 2017 if we accept that, yah

“16:24:25 SamWhited> Can we just have a general vote that all old compliance suites are superseded by the 2016 ones?”, is this in any way useful? Imo we should only have them superseded by the direct next one.

I don't really care; either way. Next one is fine.

With my editor hat on I just want to be able to move them to something-not-experimental-draft-or-final. Exactly what that looks like doesn't matter to me, as long as you can follow a chain of links and eventually get to the latest ones.

10) Vote on obsoleting old (all that are not the most recent one) Compliance Suite XEPs and marking them "superseded by" sensibly

+1

+1

+1

+1

Dave Cridland, ping

+1, sorry.

great

11) ProtoXEP: Compliance Suites 2017

i think this is Sam's

yup

did i miss the mail about this being proposed as experimental XEP?

Possibly? Maybe it didn't send and I didn't notice

i don't recall a mail either

i did not, 3 days ago " Proposed XMPP Extension: XMPP Compliance Suites 2017"

Major changes include removing MAM, adding the direct-TLS one, and that's about it I think. I have not yet gotten around to adding the other XEPs suggested by Tobias et al.

SamWhited, makes sense to vote on accepting it then, right?

err, removing MIX

not MAM

Yes please :)

MIX is now just a footnote saying to be aware that it's coming.

12) Vote on accepting http://xmpp.org/extensions/inbox/cs2017.html as Experimental XEP

+1

I have a few changes to propose, but +1 on accepting it.

+0

+1

+1

SamWhited, You're not in favour?

I'm in favor, but I figure I should abstain from voting on one of my own XEPs :)

Not that it really matters

(Mostly about making some things optional, so that e.g. web clients doing things on their server-side can still be web compliant for example, or mobile clients not on a terrible platform that force “push” notifications to get mobile approval.)

13) Discussion on adding some form of required usability considerations in XEPs, similar to Security Considerations and Acessibility Hints

I think we probably want it to be a SHOULD

Like the Internationalization section

But yes, seems worth adding it to the templtae

template*

Yes, +1 on the SHOULD.

I'd make it a MUST, that XEPs need to have it. Even if they explicitly call out "There are no usability considerations related to this XEP."

this requires changes to the template, XEP-0143

I'm fine with that too; I suppose we might as well be explicit.

and XEP-0001, which is approved by board

From the peanut gallery, I don't agree.

But then we’d need to go back to every existing XEP and add this section?

Link Mauve, would we?

Given that protocol XEPs are about what is needed for interop, not how to make good software.

Kev, security is not needed for interop

Kev, security is not needed for interop either

Kev, I thought we quite agreed that “UI” and “UX” interop was part of interop during Summit.

Advice is great, but not required, and the people competent to produce UX specs are not the same ones competent to make protocol specs.

but we sure want secure implementations, not just interopting one

Whatever these two terms extend to.

So I think a new section is desirable, and non-normatively recommending it is sensible, but not 2119 SHOULDing it.

Kev, the people competent to produce security specs are not the same ones competent to make protocol specs either, not?

I'd say that was far less clear-cut.

The security considerations in XEPs are about the use of the protocol, not the product as a whole.

I'd strongly suggest that going down this route carefully is the most sensible thing.

And to start by introducing the section and suggesting it's used, and to evaluate how that's going later.

Kev, I was expecting this to be for suggestions on how to use, for example, the Name vs Description of a MIX.

right

Kev, Not so much for "UX" concerns, per-se.

Dave Cridland: I don't think a new section is needed for that example, that' just part of the spec as-is (or will be)

I don’t remember, does this new section also covers things like “a compliant implementation MUST [display the avatar]” or whatever, or is this another topic?

I don't think "This is what these fields are for" is "Usability considerations".

i just want future XEPs to have this section, regardless if it just says "There are no usability considerations" or real considerations

so it's not forgotten

Kev, I think pulling those out is useful for, for example, consumers of a library (as opposed to those implementing the library itself).

I don't think it covers anything normative; just suggestions.

Tobias: Do you want to reject XEPs that don't have it? Or where it's not sufficiently thought-out? Will this be a barrier to Experimental, or just to Draft?

SamWhited: But you're talking about normatively requiring it.

Kev: Yes, those are two separate things

Kev, So people using Swiften, which ought to handle the interop side, so they know what the conventions are without reading the entire document.

Kev, yes... i see no issue requiring server XEPs adding a line "There are no usability considerations for this XEPs"

May I suggest that this is getting too long for the minutes and we decide to further discuss this after the meeting or on list? Or do people want to try and vote today?

SamWhited, agreed...will bring it up on the list, make the required PRs, so the respective bodies can vote on it

14) Date of next

same time, same day of the week, next week?

WFM

Wfm.

WFM

WFM

great

15) AOB

Date of next set for 2017-02-15 16:00Z

I made changes due to last call feedback on XEP-0368 and last call ends the 11th (saturday), so if it could be put on agenda for next meeting and you could check it out before then that'd be good :)

(SamWhited, s/ /T/ in your date.)

Heh, sure

moparisthebest, great..then we'll vote on advancing it next week

any other AOB?

None from me.

I like that formulation. :)

nope

yes

SamWhited, yes?

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

Also fine to hold until next week, I forgot to add a card

just want to make sure people see it

I actually totally forgot about it while we were discussing CSI and carbons earlier

alright...CSI and Carbons will have new Last Calls anyway

any other AOB?

that PR is touching way too many things at once

daniel: I agree

doesn't look like there is AOB

thanks everybody

SamWhited, thx for taking the minute notes

Whew; sorry for the massive amount of stuff all at once!

This was our longest meeting ever!

Thanks everyone

Thanks. :)

The word "and" doesn't belong in a commit message or issue report. ;)

Zash, agree!

SamWhited, but quite productive i think

Good meeting indeed. Very productive.

SamWhited, you minutes seem to have 11 points on the agenda, we discussed 15, or i counted wrong...is there stuff missing or was it just elided?

SamWhited, you minutes seem to have 11 points on the agenda, we discussed 15, or i counted wrong...is there stuff missing or was it just combined?

Tobias: I didn't think I missed anything? Maybe I did

I can't focus on the topic and take minutes at the same time, so I probably did

It apparently got held up in the moderator queue going to standards@; could someone approve it?

there's not general rush to get the minutes out ASAP, one could always check back with the MUC logs. but i agree, external minute takes would be nice

We didn't discuss it earlier, but are we okay with the shortname for Bind 2.0 being "bind2"?

SamWhited, if there's no collision, sounds sensible

mid-lengthy mail send to standards about "Usability Considerations"

Just realized that I still have no idea how to make redirects on the webserver, so every time I accept an XEP any links to the protoxep break.

SamWhited, why that?

why does it require redirects?

Tobias: Because I'll move inbox/bind2.xml to xep-0386.xml, then all the links break

But if we just leave it in the inbox, then Google continues to find the protoxep forever.

ah...you should probably copy it in git then

or not?

probably not

Maybe we need to generate a <meta rel='canonical'> or whatever it is if it's in the inbox

Or a no-index

or whatever Google likes

Redirecting the old link seems sensible though; then links in emails and things continue to work.

yes

That's what the editor README says to do anyways (it just doesn't say hohw)

*how

we could probably automatically derive redirect rules from git history, not?

Maybe? Sounds complicated

does it? just need to query moves related to inbox/* path

Git doesn't have a concept of moves, just deletes and creates, but yah, I suppose that's not much more difficult

i'll create an issue at our github repo, maybe i'll get around it over the weekend or so

probably fits into the overall idea of "Make XEP publishing more automatic" :D

That's a good point; if there is an existing way I'm happy to do it for now, but having it be automated would be pretty excellent

there is one

I dug around on the server for a bit, but couldn't even figure out how the website was being served (it didn't appear to even be the same site as the thing in the directory where the XEPs get published too), so I gave up :)

but there currently aren't any inbox redirects in place, are there?

The editor README says there are, but maybe they were lost when we moved to the new site?

send you a PM with some pointers

Thanks

Tobias: Ah, thanks, I found where the website lives at least

Yah, I don't see any redirects in here, maybe they were lost. I could just start adding new ones I guess

you could

https://github.com/xsf/xeps/issues/406 for the script idea

Thanks! In the mean time, I'll update the editor readme to point to the redirects file and tell people to add stuff in there; although I really don't want to touch the webserver, that makes me nervous I'll break things.

On second thought, maybe I won't, that sounds dangerous.

heh

one can have it check the config before a reload and at least make sure there are no syntax errors

also, these config files are git versioned

oh that's good to know, so worst case scenario I do an /etc/init.d nginx reload or whatever and it fails, and then just revert and reload again

Either way, I don't want to risk breaking the website just to add some redirects

i understand

LC flood

sorry; the process to do any editor task on the webserver is a pain in the ass, so it's a tiny bit better if I just do things in a batch where I can Ctrl+R or up arrow the history a lot.

was just joking ;)

SamWhited, some XEPs don't have the info in git though https://q.zash.se/8415528f5128.txt

but works for most recent

Nifty!

That's really cool actually; not nearly as bad as I thought it would be