XMPP Council - 2019-04-24

Ok, I've remembered why the full-JID limit is in place, and it's an attempt to avoid issues with id collisions.

re: https://github.com/xsf/xeps/pull/784/files

I don't know if that should change our opinions at all.

For https://github.com/xsf/xeps/pull/778/files (I thought you could suggest text tweaks directly in github, but I don't see how now), under mandatory support I suggest adding the text """ While future versions of this specification (or other specifications) might use a different set of delivery rules, they would signify this by advertising a namespace other than "urn:xmpp:carbons:rules:0". """ , which I think matches what I suggested/requested last week. Ge0rG ^

Kev: that's a great suggestion. I pondered about writing something along those lines, but then I realized that this is exactly why you have versioned namespaces in the first place, and thus considered it redundant

Half, yes. There's an ulterior motive there, which is that it's a get-out clause for letting us change things during Draft that otherwise would be more difficult :)

By mentioning that more changes might come later.

Kev: https://github.com/xsf/xeps/pull/778/commits/e6cb1297f3a70b5f32af39250bd19951ec3c063d

Kev: you claimed to have started a list discussion on https://github.com/xsf/xeps/pull/779 but I don't see anything.

*hem* *hem*

Afternoon.

1) Roll Call

.

Here.

Link? Or are we Linkless today?

Unlinked?

Unlinkly

Ge0rG: if it helps your search, I said this about 779: """ This seems a little backwards to me - it’s only saying the completely non-normative 'is a good practice’ for doing the right thing, while saying ’should’ (yes, I realise lower case) accept the wrong thing. Should we not SHOULD doing the right thing? /K """

Unlunk, then.

2) Agenda Bashing

let's put #779 on the agenda then?

OK, so Georg's suggested agenda plus #779.

The only source of agenda items that I wanted to push onto everybody was what I came up with in the last week.

I checked open PRs for "Council Needed", but don't know about proto XEPs or other issues

I'm in the office on a poor excuse for a computer, so I'm a bit rubbish today, but:

3) Items for voting.

a) #778 (XEP-0280 rules bit)

+1 on #778

I'm very much +1 on this.

Please consider that it received another small update just one hour prior to this Meeting.

I think I'm +1, but I'll re-review properly if I have the time.

I'm +1 if I can have my text from earlier (bonus points if it also changes back to MAY when not using the feature ,but not blocking)

(But assume +1)

dwd: _when_ you have the time?

Ah, my tweak's already in. +1 then.

Kev: your text is already in

Ge0rG, I appreciate your optimism. I should do tonight.

Actually, the SHOULD->MAY change is something we MAY discuss today

I think that's everyone +1, with Link Mauve on list.

And I'll suggest discussion later in AOB, if that's OK?

With the new feature (does the name `urn:xmpp:carbons:rules:0` sound right to you?) I don't insist on SHOULDing the rules by default

b) #787 (Xep-0045, kill GC-1.0 with fire)

Ge0rG: I'd prefer SHOULD->MAY, but not a hill for me.

+1 on #787

+1 on #787

urn...carbons:rules:0 seems fine to me.

+1 on this from me.

+1 on 787. I note that I'm not convinced it won't break anything, but progress and all that.

Kev, My conclusion was that it'll break things, but break them cleanly.

Kev: prosody 0.11 was rolled out without GC1 and there was no Major Backlash

Major Backlash, reporting for duty.

c) #779 (I don't know what this is, even)

We can rename it into GCexit if that suits you more.

Ge0rG: I'd like an extension, please.

#779 is about an informative box in 0184 regarding the message @type

https://github.com/xsf/xeps/pull/779/files is what we discussed two weeks ago.

Yes, I was thinking this looked familiar.

My onlist response was > This seems a little backwards to me - it’s only saying the completely non-normative 'is a good practice’ for doing the right thing, while saying ’should’ (yes, I realise lower case) accept the wrong thing. Should we not SHOULD doing the right thing?

https://mail.jabber.org/pipermail/standards/2019-April/036083.html

Kev: I can uppercase it.

but I won't uppercase the "must" in the MUC section

It's the other way around though, I think.

At the moment we're not should nor SHOULDing doing the right thing (matching type).

because an implementation might want to realize MUC receipts as a MUC-PM

We're only shoulding what to do if you receive the wrong thing (different type).

I suggest s/It is a good proctice to/A client SHOULD/, I think.

(ignoring my typos)

I'll have a premptivee +1 on this. I'm pretty sure it's more or less right and that you two will figure outt the precise language here.

Kev: that would be a normative change.

I think requiring the client to match non-matching types already is.

I agree that it's the Right Thing, but I wasn't brave enough to introduce _that_

Kev: prior versions didn't have any requirements on the incoming message type, so... no?

Hrmm.

you could therefore argue that a client MUST accept different message types.

In that case, I'd suggest dropping that SHOULD back to a should, and brushing it under the carpet.

Kev: I just added a patch to the PR containing the SHOULD.

Yeah, ok.

Now you made me regret it.

Do we have enough +1s to pass if I +0? :)

Yes.

jonas’ ?

+0 then.

> PR #779 - XEP-0184: add a box about types and JIDs - https://github.com/xsf/xeps/pull/779 > Dave: [pending] > Georg: +1 > Jonas: +1 > Kev: [on-list] > Link: +1

still +1

Yeah, I think I voted +1 afterward/

And I'm still +1 whatever you guys decide on this.

Is it an AOB to actually decide that?

The branch as-is is what's going in, I think.

And while I don't think it's quite right, I'm ok with that.

OK.

4) Outstanding Votes.

I have no clue today. But please check if you have any oustanding votes and vote them, outstandingly.

5) AOB

I believe I'm completely up to date now, unusually.

mayeb we should re-discuss that PR I brought up on the list again

I'm pending on #736 because we need feedback from Link Mauve

jonas’: which one would that be?

-> https://github.com/xsf/xeps/pull/758 for next agenda maybe, I think it was technically vetoed but I’d like to re-open discussion on that one

because Kevs reasoning is unclear to me.

What was my reasoning? :)

here’s my respones to your reasoning: https://mail.jabber.org/pipermail/standards/2019-April/036059.html

here’s your original reasoning: https://mail.jabber.org/pipermail/standards/2019-March/035888.html

nobody remembers, so move it to next week or have it added to AOB?

Ah, I remember, excellent.

This is in 5.4 https://xmpp.org/extensions/xep-0060.html#entity-metadata

Which says "If metadata is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like."

So I think if you add more options here, you SHOULD now include them (if you include any).

And so I think the claim that it doesn't change conformance wasn't right.

Right, and jonas’'s argument is that by the wording there, the access-model SHOULD already be included.

Ah, hrmm.

Yeah, I buy that argument.

I suspect the practical solution would be to change the "it SHOULD" to "implementations are encouraged" in order to reflect reality.

Ah, no, because there is a registry in there for the form_type

And this is adding to it.

No?

dwd: this is the worst way to improve an XEP.

it is, but it is still a configuration option

and it still should be reflected in there

Ge0rG, Indeed. But we then add a feature that says "I do this bit right".

dwd: that's better. Or we write into the XEP that before version 1.23.42, the behavior was different and that the other end must cope with old entities.

Ge0rG, My way is more interoperable, I think.

I don’t think that applies in this case

Ge0rG, But yes.

because the set of configuration options is already rather fuzzy

dwd: I'm not sure I agree.

The set of config options is, but the set of config options you're allowed to include in pubsub#metadata isn't.

As there's a registry for that.

Ge0rG, You can do both, mind.

But this is all a meta discussion because 0060 would overload my capacity today.

Kev, a registry is mutable though

Kev, Registries are intended to be changed outside the XEP that defines them though.

Fair.

Yeah, I withdraw my -1.

I think we’d have to formally re-vote given that the voting period is looong over

Shove it on next week's agenda, that gives me 7 days to have an excuse to be belligerent.

jonas’, I don't think we need to, actually. The wording in XEP-0001 isn't clear, but the phrasing suggests that a COuncil person withdrawing their objection is sufficient.

I’d expect this to be more in hte bylaws than in '1

Happy to revote if people *want*, mind. ✏

but I don’t care a lot, i’m fine with just kev withdrawing the vote and we go ahead

Votes are cheap, I think the precedent of publishing something that was long ago vetod is not one to set.

jonas’, Nope, standards process, not by-laws.

Fair enough, I'll stick it on next week then.

alright

Unless we want to +1 it now ,in which case +1.

But I'd rather just end the meeting on time :)

Yeah, even better.

Hah, too late:

not yet ;)

There are still AOBs.

(too slow) ✏

I'm still +0

Well, given we've hit the half hour, I'll cut us short, but feel free to continue chatting.

6) Next Meeting

+1W?

wfm

7) Ite Meeting Est

+2W for me.

Ge0rG, Noted.

and it will be a +3W after that one.

Technically, I'm not totally gone, but I'll most probably be in holiday mode away from a PC, and keeping up with Councils on a mobile is _hard_.

Ge0rG, Nice.

Ge0rG, so you’ll be able to vote on-list?

so back to #779. I actually wanted to ask Council whether we want to move on with putting normative language on The Right Thing into the XEP, or whether the fig leaf note box is the best trade-off I can get.

jonas’: given that I'll be gone for two weeks, and the two week voting period, I'm much confident that yes.

very good

hi

so let's see the vote next week then :)