Ok, I've remembered why the full-JID limit is in place, and it's an attempt to avoid issues with id collisions.
Kev
re: https://github.com/xsf/xeps/pull/784/files
Kev
I don't know if that should change our opinions at all.
Kev
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 ^
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
Kev
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 :)
Kev: you claimed to have started a list discussion on https://github.com/xsf/xeps/pull/779 but I don't see anything.
Ge0rG
*hem* *hem*
dwd
Afternoon.
dwd
1) Roll Call
jonas’
.
peterhas joined
Kev
Here.
Ge0rG.o/
dwd
Link? Or are we Linkless today?
dwd
Unlinked?
jonas’
Unlinkly
Kev
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
"""
dwd
Unlunk, then.
dwd
2) Agenda Bashing
Ge0rG
let's put #779 on the agenda then?
dwd
OK, so Georg's suggested agenda plus #779.
Ge0rG
The only source of agenda items that I wanted to push onto everybody was what I came up with in the last week.
Ge0rG
I checked open PRs for "Council Needed", but don't know about proto XEPs or other issues
dwd
I'm in the office on a poor excuse for a computer, so I'm a bit rubbish today, but:
dwd
3) Items for voting.
dwd
a) #778 (XEP-0280 rules bit)
jonas’
+1 on #778
Ge0rG
I'm very much +1 on this.
Ge0rG
Please consider that it received another small update just one hour prior to this Meeting.
dwd
I think I'm +1, but I'll re-review properly if I have the time.
Kev
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)
dwd
(But assume +1)
Ge0rG
dwd: _when_ you have the time?
Kev
Ah, my tweak's already in. +1 then.
Ge0rG
Kev: your text is already in
dwd
Ge0rG, I appreciate your optimism. I should do tonight.
Ge0rG
Actually, the SHOULD->MAY change is something we MAY discuss today
dwd
I think that's everyone +1, with Link Mauve on list.
dwd
And I'll suggest discussion later in AOB, if that's OK?
Ge0rG
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
dwd
b) #787 (Xep-0045, kill GC-1.0 with fire)
Kev
Ge0rG: I'd prefer SHOULD->MAY, but not a hill for me.
Ge0rG
+1 on #787
jonas’
+1 on #787
Kev
urn...carbons:rules:0 seems fine to me.
dwd
+1 on this from me.
Kev
+1 on 787. I note that I'm not convinced it won't break anything, but progress and all that.
dwd
Kev, My conclusion was that it'll break things, but break them cleanly.
Ge0rG
Kev: prosody 0.11 was rolled out without GC1 and there was no Major Backlash
Kev
Major Backlash, reporting for duty.
dwd
c) #779 (I don't know what this is, even)
Ge0rG
We can rename it into GCexit if that suits you more.
Kev
Ge0rG: I'd like an extension, please.
Ge0rG
#779 is about an informative box in 0184 regarding the message @type
Kev
https://github.com/xsf/xeps/pull/779/files is what we discussed two weeks ago.
dwd
Yes, I was thinking this looked familiar.
Kev
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?
but I won't uppercase the "must" in the MUC section
Kev
It's the other way around though, I think.
Kev
At the moment we're not should nor SHOULDing doing the right thing (matching type).
Ge0rG
because an implementation might want to realize MUC receipts as a MUC-PM
Kev
We're only shoulding what to do if you receive the wrong thing (different type).
Kev
I suggest s/It is a good proctice to/A client SHOULD/, I think.
Kev
(ignoring my typos)
dwd
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.
Ge0rG
Kev: that would be a normative change.
Kev
I think requiring the client to match non-matching types already is.
Ge0rG
I agree that it's the Right Thing, but I wasn't brave enough to introduce _that_
Ge0rG
Kev: prior versions didn't have any requirements on the incoming message type, so... no?
Kev
Hrmm.
Ge0rG
you could therefore argue that a client MUST accept different message types.
Kev
In that case, I'd suggest dropping that SHOULD back to a should, and brushing it under the carpet.
Ge0rG
Kev: I just added a patch to the PR containing the SHOULD.
Kev
Yeah, ok.
Ge0rG
Now you made me regret it.
Kev
Do we have enough +1s to pass if I +0? :)
Ge0rG
Yes.
dwd
jonas’ ?
Kev
+0 then.
Ge0rG
> 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
jonas’
still +1
dwd
Yeah, I think I voted +1 afterward/
dwd
And I'm still +1 whatever you guys decide on this.
Ge0rG
Is it an AOB to actually decide that?
Kev
The branch as-is is what's going in, I think.
Kev
And while I don't think it's quite right, I'm ok with that.
dwd
OK.
dwd
4) Outstanding Votes.
debaclehas left
dwd
I have no clue today. But please check if you have any oustanding votes and vote them, outstandingly.
dwd
5) AOB
Kev
I believe I'm completely up to date now, unusually.
jonas’
mayeb we should re-discuss that PR I brought up on the list again
Ge0rG
I'm pending on #736 because we need feedback from Link Mauve
Ge0rG
jonas’: which one would that be?
jonas’
-> 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
jonas’
because Kevs reasoning is unclear to me.
Kev
What was my reasoning? :)
jonas’
here’s my respones to your reasoning: https://mail.jabber.org/pipermail/standards/2019-April/036059.html
jonas’
here’s your original reasoning: https://mail.jabber.org/pipermail/standards/2019-March/035888.html
Ge0rG
nobody remembers, so move it to next week or have it added to AOB?
Kev
Ah, I remember, excellent.
Kev
This is in 5.4 https://xmpp.org/extensions/xep-0060.html#entity-metadata
Kev
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."
Kev
So I think if you add more options here, you SHOULD now include them (if you include any).
Kev
And so I think the claim that it doesn't change conformance wasn't right.
dwd
Right, and jonas’'s argument is that by the wording there, the access-model SHOULD already be included.
Kev
Ah, hrmm.
dwdlikes typing "jonas’'s" because of the fun punctuation.
Kev
Yeah, I buy that argument.
dwd
I suspect the practical solution would be to change the "it SHOULD" to "implementations are encouraged" in order to reflect reality.
Kev
Ah, no, because there is a registry in there for the form_type
Kev
And this is adding to it.
Kev
No?
Ge0rG
dwd: this is the worst way to improve an XEP.
jonas’
it is, but it is still a configuration option
jonas’
and it still should be reflected in there
dwd
Ge0rG, Indeed. But we then add a feature that says "I do this bit right".
Ge0rG
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.
dwd
Ge0rG, My way is more interoperable, I think.
jonas’
I don’t think that applies in this case
dwd
Ge0rG, But yes.
jonas’
because the set of configuration options is already rather fuzzy
Ge0rG
dwd: I'm not sure I agree.
Kev
The set of config options is, but the set of config options you're allowed to include in pubsub#metadata isn't.
Kev
As there's a registry for that.
dwd
Ge0rG, You can do both, mind.
Ge0rG
But this is all a meta discussion because 0060 would overload my capacity today.
jonas’
Kev, a registry is mutable though
dwd
Kev, Registries are intended to be changed outside the XEP that defines them though.
Kev
Fair.
Kev
Yeah, I withdraw my -1.
jonas’
I think we’d have to formally re-vote given that the voting period is looong over
Kev
Shove it on next week's agenda, that gives me 7 days to have an excuse to be belligerent.
dwd
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.
Well, given we've hit the half hour, I'll cut us short, but feel free to continue chatting.
dwd
6) Next Meeting
dwd
+1W?
jonas’
wfm
dwd
7) Ite Meeting Est
Ge0rG
+2W for me.
dwd
Ge0rG, Noted.
Ge0rG
and it will be a +3W after that one.
Ge0rG
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_.
dwd
Ge0rG, Nice.
jonas’
Ge0rG, so you’ll be able to vote on-list?
Ge0rG
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.
Ge0rG
jonas’: given that I'll be gone for two weeks, and the two week voting period, I'm much confident that yes.