XMPP Council - 2019-01-09

Good morning!

Hi.

Did we have an agenda btw?

yeah!

We did, because I got around to it.

Yes, Dave sent it out yesterday.

!praise dwd

I've not got around to my Voting Bot, though.

Oh, just now I see it. :x

I still don’t see the agenda

where is it?

[Council] Council Agenda 2019-01-09

is that a mailing list?

separate from standards@?

jonas’, it is council@.

I’m not on that list

Oh.

Alex should have added you after the elections.

haven’t been added, afaict

If you mail me, I'm probably capable of doing the magic.

I have two things which look like they may be email addresses of yours

isode please.

okay

sent

Received.

awsum

'tis time.

let’s just do IM over email!

(oh somebody already did ;-))

Oh, it's time for a meeting!

It's not IM over email, it's TODO list over email :)

:D

1) Roll Call

I'm here. I think.

afaict

Ge0rG, ?

\o/

I'm here too. Apologies for last week.

2) Agenda Bashing

same, I was caught up in house cleaning and totally forgot about day of week and time of day

Did I forget anything?

LGTM

I can’t tell, I haven’t seen the agenda

jonas’, Have you not?

probably we should split 6a (PR #727) into individual LCs for process' sake

no, I’m not on council@ as we discussed just now

Kev will take care

but I’ll just shout in AOB if something is missing or so

Oh. Whoops. I normally cc it to standards as well.

My mistake, anyway.

thanks

3) Items for voting: a) Proposed XMPP Extension: Order-By Abstract: This specification allows to change order of items retrieval in a Pubsub or MAM query URL: https://xmpp.org/extensions/inbox/order-by.html

Is that a vote or discussion first?

That's a vote for adoption, I believe.

I tend to -1, because it's a very specific use case, and it defines two hard-coded properties to order by. A clean approach would allow ordering by any field of the items, using some XSLT magic or something.

I’m on-list in any case, I want to discuss with goffi a bit, because I’m pretty sure that I’m right about the points I raised ;-)

Ge0rG, note, it defines properties which live *outside* the items, determined by the server

it could easily be extended to support XPath or anything like that though

I'm not keen on it, but it clears my bar-of-incompetence for Experimental. So +1.

jonas’: yes. But is there any reason not to embed those properties in the items?

Ge0rG, Yeah, this is indeed ordering by metadata external to the item payload.

Ge0rG, yes, the server shalt not modify the items

jonas’: what's wrong with the client adding the respective stamps?

Ge0rG, goffi doesn’t find that correct (which I disagree with), because it can be "spoofed"

see the discussion on-list for that

oh, didn't catch-up on that.

So I'm on-list, with fallback to -1.

what’s your rationale for your fallback -1?

At least this needs to be renamed "PubSub MAM retrieval ordered by creation or modification"

I’m on list on that, I haven’t caught up with anything yet.

I did notice this applies to MAM, too, but doesn't disucss it, and presumably has quite an impact on RSM, but doesn't mention that.

(I’ll try to get better soon!)

(OT: Subject: Welcome to the "Council" mailing list. Thanks Kev)

dwd, it doesn’t have an impact on RSM, it happens before RSM even comes into play.

although, the server might have to use different identifiers in RSM to make it work with RSM

jonas’, I think that needs mentioning. Or thinking about.

It does have an interaction with RSM, at least. Whether 'impact' or not is up to linguists :)

dwd, I agree

I wouldn't be unhappy to see this have more work on it before it's published, but I couldn't find a reason to veto it using my usual criteria.

afaict, all except Kev are on-list?

jonas’: my rationale is that it's only adressing a very specific use case, and requires changes to multiple other XEPs, like PubSub (for storing metadata). However, I suppose that's not an appropriate reason for rejecting a proto-XEP

no, dwd hasn’t said anything yet

Yeah, I'll go with +0.

it doesn’t require changes to XEPs

(Though I reserve the right to change that while others are still on-list).

jonas’: it implies changes to their implementation.

that’s true

but those are two different things

(kinda important when one of the affected XEPs is Draft)

OK, moving on.

4) Outstanding Votes

I don't think we have any, do we? I can't imagine we do anyway.

5) Next Meeting

I can't remember any, but maybe this is the right time to remind about the Spreadsheet of Doom?

Or something.

Same time next week?

wfm

WFM, I think.

I'll assume 2019-01-16 1600Z unless anyone shouts.

will *probably* work for me. If it does not, it will be impacting my availability for the next ~3mo, so we might need to reschedule or to on-list Ge0rG

Ge0rG, Ah... Should we reschedule now?

My employer translocates me into another city for a full-time engagement, and I don't know the specific business hours there yet

I'll hopefully know more by +1W

Ah, OK. Keep us posted; we can rearrange via email if it's a semi-permanent thing.

6) AOB a) Cleaning up Deferred items. Link's PR #727 seems unresolved - we should decide on a suitable way to handle this.

These two AOBs are basically about cleaning the github issues and PRs out, so it's more obvious what I should put on the agenda.

That's the obsoleting? We vote on the obsoletes don't we?

the PR as is cannot be applied, so I (Council Member) propose I (Editor) just close this

So, a) is a process issue.

Kev: IIRC we can't vote to obsolete without an LC, and probably we shouldn't anyway

and if we want to have process for that, we need to propose a modification of XEP-0001

We are not allowed (?) to obsolete without a last call first.

We can't apply #727 as-is, due to a mismatch in the process, so does someone want to take on changing the process, or do we just not care about clearing out old deferred XEPs?

So why not just vote on an LC for each of them? ✏

But I still believe obsolete is the correct status for these three XEPs (and more, but I wanted to start small).

they have to pass to draft to allow obsoleetion, Ge0rG

jonas’, There's Proposed->Rejected

Rejected ≠ Obsolete, but Rejecting would be an option, too

Sorry, why can't we go from Deprecated to Obsolete? That's what 9.10 says we can do :)

I'd be fine with Rejected, actually. Feels more accurate. But again, process.

Kev, they’re deferred, not deprecated

Kev, We can -but these are Deferred, not Deprecated, I thought?

Oh, right.

We have Retracted, but I'd prefer not to use that personally. I'd happily go for allowing Deferred->Rejected though.

vote for rejection without asking the community at all?

So, two questions: What do we want the process to be, and who wants to draft the PR to XEP-0001?

issue a "Call for Deprecation"?

I can do the PR to XEP-0001

And the third question: Is there a problem with Deferred XEPs staying Deferred?

not for me (as Editor)

Kev, Well, yes - if we're happy with the process as-is.

I suggest that we add an arrow from "Proposed" to "Deprecated"

I would note that it's much the same as expired Internet Drafts in the IETF, and those sometimes get "unexpired" years later.

I'm not sure I see a particular problem with something being Deferred for eternity, when it seems to reflect the actual state - abandoned before advancement.

Kev, the main problem I want to solve is that we’ve asked people to read (big red warning) deferred XEPs for quite a while, because our process is way too slow.

Kev: I think that "Deprecated" is a stronger signal not to implement it than "Deferred"

What Link Mauve says!

Link Mauve, but then it is more worthwhile to tackle the XEPs which actually have a chance to advance

and which should advance

and not those which are dead anyways

Link Mauve: Isn't the problem there getting things out of Deferred when they're not really Deferred, rather than getting them out when they are.

jonas’, sure, in the end I’d like to do both.

jonas’: you can't force other people to implement your XEPs

Link Mauve, Right, moving a XEP from Deferred is easy. And I'm not sure how we could make it "faster".

Kev, whynotboth.jpg

focus on the other part first, maybe, becauise the Deferred ones which are actually abandoned and should be aren’t the actual issue

Ge0rG, You don't need to, to move to Draft.

Ge0rG, you don’t need implementations to move to Draft

Also, I’ve in the past fixed a typo in a deferred XEP which put it back to experimental.

ah well.

I’d like to avoid doing that everytime there is a typo.

Link Mauve, I agree

(And I hate typos. :p)

Link Mauve: that shouldn't happen, as editorial changes shouldn't count against Deferral

this needs fixing, but is also separate

Ge0rG, there are varying opinions on that

we should ask Board to clarify maybe

some people say "if someone cares enough to fix a typo, it should become undeferred"

I still propose a new arrow from "Proposed" to "Deprecated", after which we can LC those and bury them.

others (me, for example) say "only non-editorial changes should un-defer"

jonas’: next time I submit a proto-XEP, I'll add a dozen typos to keep it in Experimental

OK, so no agreement - can someone take this to standards@ please? (I suggest someone who wants things to change)

If we allow proposed going to deprecation, I don't oppose it.

I'm just not convinced it's worth any of my cycles.

... and if nobody does, I'll assume nobody wants it to change.

dwd: we could vote on allowing "Proposed" --> "Deprecated" and then add it to tomorrow's Board agenda.

b) Tidying examples in XEP-0045 Flow's PR #715 remains unmerged.

Ge0rG, Nah. I don't think there's sufficient agreement to worry, and I'd rather ping the community first.

6b: IIRC we had a discussion that ended with disagreement between some council members and flow about what's the right thing.

So this PR came up last year, and I think we buried it in discussion about whether disco#info needed to be listed in a disco#info response.

Which was another (related) PR.

(Also by Flow)

Imo fixing examples to match 0030’s text is a no brainer.

Right. This PR only adds disco#info to examples.

My recollection is that Council decided that disco#info MUST be listed, as XEP-0030 says. Therefore we should presumably apply this one to fix the examples?

That’s also what I remember.

(I mean, I dissented on that one, but whatever)

dwd: that will make the examples look more normative and less example-y, won't it?

Ge0rG, I think they'll still look exampley, they'll just be better examples.

for certain definitions of better

jonas’, More accurate.

it is not relevant to the implementation of XEP-0045 itself

and more noisy

I think that an example should focus on the things relevant to *this* XEP and not on boilerplate from other specs.

jonas’, And pointless. But that's what Council voted for, so...

I'm low-F on this. I'd rather like it if we were able to list only the bits relevant to a XEP in a XEP's example disco, but whatever.

dwd: Council voted on disco#info being part of the response, not part of the examples of each XEP.

I'm -0 on PR#715, because I like my examples short and focused.

I'm happy not to care. I'm unhappy if we don't close this one way or another though.

So, apply or not: It's votin' time!

-0

-0. Don't care.

-0

Link Mauve, ?

I think it’d be useful to add “...” on a separate line to make them look more exampl-y, but +1.

Link Mauve, that would be even better IMO

Link Mauve: that's an excellent proposal!

Link Mauve, Yeah, I'd be fine with that. I'd consider it editorial too.

or even better, <!-- ... -->, which wuoldn’t break schema validation

jonas’, That too.

jonas’: 👍

jonas’, a previous council rejected this usage. :p

pft

Link Mauve, Really?

this council seems to be rather happy with it

dwd, I think it was for the CLIENT: and SERVER: parts.

Ah, probably.

But I’m +1 for this usage too.

those are kaputt anyways

Anyway, that's all folks.

7) Ite, Meeting Est.

Link Mauve, you +1’d the other PR so we’ll have both now?

jonas’, both sounds more fine than none or either.

how does it sound more fine than either, considering the noise factor?

Thanks Dave