If you mail me, I'm probably capable of doing the magic.
jonas’
I have two things which look like they may be email addresses of yours
Kev
isode please.
jonas’
okay
jonas’
sent
Kev
Received.
jonas’
awsum
Kev
'tis time.
jonas’
let’s just do IM over email!
jonas’
(oh somebody already did ;-))
dwd
Oh, it's time for a meeting!
Kev
It's not IM over email, it's TODO list over email :)
jonas’
:D
dwd
1) Roll Call
Kev
I'm here. I think.
jonas’is here
jonas’
afaict
Link Mauveis here too.
jonas’
Ge0rG, ?
lnjhas left
Ge0rG.o/
jonas’
\o/
dwd
I'm here too. Apologies for last week.
dwd
2) Agenda Bashing
jonas’
same, I was caught up in house cleaning and totally forgot about day of week and time of day
dwd
Did I forget anything?
Ge0rG
LGTM
jonas’
I can’t tell, I haven’t seen the agenda
dwd
jonas’, Have you not?
Ge0rG
probably we should split 6a (PR #727) into individual LCs for process' sake
jonas’
no, I’m not on council@ as we discussed just now
jonas’
Kev will take care
jonas’
but I’ll just shout in AOB if something is missing or so
dwd
Oh. Whoops. I normally cc it to standards as well.
Ge0rGalso just bounced the Agenda mail to jonas’, just in case.
dwd
My mistake, anyway.
jonas’
thanks
dwd
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
Ge0rG
Is that a vote or discussion first?
dwd
That's a vote for adoption, I believe.
Ge0rG
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.
jonas’
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 ;-)
jonas’
Ge0rG, note, it defines properties which live *outside* the items, determined by the server
jonas’
it could easily be extended to support XPath or anything like that though
Kev
I'm not keen on it, but it clears my bar-of-incompetence for Experimental. So +1.
Ge0rG
jonas’: yes. But is there any reason not to embed those properties in the items?
dwd
Ge0rG, Yeah, this is indeed ordering by metadata external to the item payload.
jonas’
Ge0rG, yes, the server shalt not modify the items
Ge0rG
jonas’: what's wrong with the client adding the respective stamps?
jonas’
Ge0rG, goffi doesn’t find that correct (which I disagree with), because it can be "spoofed"
jonas’
see the discussion on-list for that
Ge0rG
oh, didn't catch-up on that.
Ge0rG
So I'm on-list, with fallback to -1.
jonas’
what’s your rationale for your fallback -1?
Ge0rG
At least this needs to be renamed "PubSub MAM retrieval ordered by creation or modification"
Link Mauve
I’m on list on that, I haven’t caught up with anything yet.
dwd
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.
Link Mauve
(I’ll try to get better soon!)
jonas’
(OT: Subject: Welcome to the "Council" mailing list. Thanks Kev)
jonas’
dwd, it doesn’t have an impact on RSM, it happens before RSM even comes into play.
jonas’
although, the server might have to use different identifiers in RSM to make it work with RSM
dwd
jonas’, I think that needs mentioning. Or thinking about.
Kev
It does have an interaction with RSM, at least. Whether 'impact' or not is up to linguists :)
jonas’
dwd, I agree
Kev
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.
lnjhas joined
jonas’
afaict, all except Kev are on-list?
Ge0rG
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
jonas’
no, dwd hasn’t said anything yet
dwd
Yeah, I'll go with +0.
jonas’
it doesn’t require changes to XEPs
dwd
(Though I reserve the right to change that while others are still on-list).
Ge0rG
jonas’: it implies changes to their implementation.
jonas’
that’s true
jonas’
but those are two different things
jonas’
(kinda important when one of the affected XEPs is Draft)
dwd
OK, moving on.
dwd
4) Outstanding Votes
dwd
I don't think we have any, do we? I can't imagine we do anyway.
dwd
5) Next Meeting
Ge0rG
I can't remember any, but maybe this is the right time to remind about the Spreadsheet of Doom?
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
dwd
Ge0rG, Ah... Should we reschedule now?
Ge0rG
My employer translocates me into another city for a full-time engagement, and I don't know the specific business hours there yet
Ge0rG
I'll hopefully know more by +1W
dwd
Ah, OK. Keep us posted; we can rearrange via email if it's a semi-permanent thing.
dwd
6) AOB
a) Cleaning up Deferred items.
Link's PR #727 seems unresolved - we should decide on a suitable way to handle this.
dwd
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.
Kev
That's the obsoleting? We vote on the obsoletes don't we?
jonas’
the PR as is cannot be applied, so I (Council Member) propose I (Editor) just close this
Link Mauve
So, a) is a process issue.
Ge0rG
Kev: IIRC we can't vote to obsolete without an LC, and probably we shouldn't anyway
jonas’
and if we want to have process for that, we need to propose a modification of XEP-0001
Link Mauve
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?
But I still believe obsolete is the correct status for these three XEPs (and more, but I wanted to start small).
jonas’
they have to pass to draft to allow obsoleetion, Ge0rG
dwd
jonas’, There's Proposed->Rejected
jonas’
Rejected ≠ Obsolete, but Rejecting would be an option, too
Kev
Sorry, why can't we go from Deprecated to Obsolete? That's what 9.10 says we can do :)
dwd
I'd be fine with Rejected, actually. Feels more accurate. But again, process.
jonas’
Kev, they’re deferred, not deprecated
dwd
Kev, We can -but these are Deferred, not Deprecated, I thought?
Kev
Oh, right.
dwd
We have Retracted, but I'd prefer not to use that personally. I'd happily go for allowing Deferred->Rejected though.
jonas’
vote for rejection without asking the community at all?
dwd
So, two questions: What do we want the process to be, and who wants to draft the PR to XEP-0001?
Ge0rG
issue a "Call for Deprecation"?
jonas’
I can do the PR to XEP-0001
Kev
And the third question: Is there a problem with Deferred XEPs staying Deferred?
jonas’
not for me (as Editor)
dwd
Kev, Well, yes - if we're happy with the process as-is.
Ge0rG
I suggest that we add an arrow from "Proposed" to "Deprecated"
dwd
I would note that it's much the same as expired Internet Drafts in the IETF, and those sometimes get "unexpired" years later.
Kev
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.
Link Mauve
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.
Ge0rG
Kev: I think that "Deprecated" is a stronger signal not to implement it than "Deferred"
Ge0rG
What Link Mauve says!
jonas’
Link Mauve, but then it is more worthwhile to tackle the XEPs which actually have a chance to advance
jonas’
and which should advance
jonas’
and not those which are dead anyways
Kev
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.
Link Mauve
jonas’, sure, in the end I’d like to do both.
Ge0rG
jonas’: you can't force other people to implement your XEPs
dwd
Link Mauve, Right, moving a XEP from Deferred is easy. And I'm not sure how we could make it "faster".
Link Mauve
Kev, whynotboth.jpg
jonas’
focus on the other part first, maybe, becauise the Deferred ones which are actually abandoned and should be aren’t the actual issue
dwd
Ge0rG, You don't need to, to move to Draft.
jonas’
Ge0rG, you don’t need implementations to move to Draft
Link Mauve
Also, I’ve in the past fixed a typo in a deferred XEP which put it back to experimental.
lnjhas left
Ge0rG
ah well.
Link Mauve
I’d like to avoid doing that everytime there is a typo.
jonas’
Link Mauve, I agree
Link Mauve
(And I hate typos. :p)
Ge0rG
Link Mauve: that shouldn't happen, as editorial changes shouldn't count against Deferral
jonas’
this needs fixing, but is also separate
jonas’
Ge0rG, there are varying opinions on that
jonas’
we should ask Board to clarify maybe
jonas’
some people say "if someone cares enough to fix a typo, it should become undeferred"
Ge0rG
I still propose a new arrow from "Proposed" to "Deprecated", after which we can LC those and bury them.
jonas’
others (me, for example) say "only non-editorial changes should un-defer"
Ge0rG
jonas’: next time I submit a proto-XEP, I'll add a dozen typos to keep it in Experimental
dwd
OK, so no agreement - can someone take this to standards@ please? (I suggest someone who wants things to change)
Ge0rGvolunteers Link Mauve :D
Kev
If we allow proposed going to deprecation, I don't oppose it.
Link Mauvevolunteers too.
Kev
I'm just not convinced it's worth any of my cycles.
dwd
... and if nobody does, I'll assume nobody wants it to change.
Ge0rG
dwd: we could vote on allowing "Proposed" --> "Deprecated" and then add it to tomorrow's Board agenda.
dwd
b) Tidying examples in XEP-0045
Flow's PR #715 remains unmerged.
dwd
Ge0rG, Nah. I don't think there's sufficient agreement to worry, and I'd rather ping the community first.
lnjhas joined
Ge0rG
6b: IIRC we had a discussion that ended with disagreement between some council members and flow about what's the right thing.
dwd
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.
dwd
Which was another (related) PR.
dwd
(Also by Flow)
Link Mauve
Imo fixing examples to match 0030’s text is a no brainer.
Ge0rG
Right. This PR only adds disco#info to examples.
dwd
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?
Link Mauve
That’s also what I remember.
dwd
(I mean, I dissented on that one, but whatever)
Ge0rG
dwd: that will make the examples look more normative and less example-y, won't it?
dwd
Ge0rG, I think they'll still look exampley, they'll just be better examples.
jonas’
for certain definitions of better
dwd
jonas’, More accurate.
jonas’
it is not relevant to the implementation of XEP-0045 itself
jonas’
and more noisy
Ge0rG
I think that an example should focus on the things relevant to *this* XEP and not on boilerplate from other specs.
dwd
jonas’, And pointless. But that's what Council voted for, so...
Kev
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.
Ge0rG
dwd: Council voted on disco#info being part of the response, not part of the examples of each XEP.
Ge0rG
I'm -0 on PR#715, because I like my examples short and focused.
dwd
I'm happy not to care. I'm unhappy if we don't close this one way or another though.
dwd
So, apply or not: It's votin' time!
jonas’
-0
Kev
-0. Don't care.
dwd
-0
dwd
Link Mauve, ?
Link Mauve
I think it’d be useful to add “...” on a separate line to make them look more exampl-y, but +1.
jonas’
Link Mauve, that would be even better IMO
Ge0rG
Link Mauve: that's an excellent proposal!
dwd
Link Mauve, Yeah, I'd be fine with that. I'd consider it editorial too.
jonas’
or even better, <!-- ... -->, which wuoldn’t break schema validation
dwd
jonas’, That too.
Ge0rG
jonas’: 👍
lnjhas left
Link Mauve
jonas’, a previous council rejected this usage. :p
jonas’
pft
dwd
Link Mauve, Really?
jonas’
this council seems to be rather happy with it
Link Mauve
dwd, I think it was for the CLIENT: and SERVER: parts.
dwd
Ah, probably.
Link Mauve
But I’m +1 for this usage too.
jonas’
those are kaputt anyways
dwd
Anyway, that's all folks.
dwd
7) Ite, Meeting Est.
jonas’
Link Mauve, you +1’d the other PR so we’ll have both now?
Link Mauve
jonas’, both sounds more fine than none or either.
jonas’
how does it sound more fine than either, considering the noise factor?