-
Ge0rG
jonas’: I've pushed a new branch to gitlab, and got this on the shell: remote: To create a merge request for xep-0308, visit: remote: https://gitlab.com/ge0rg/xeps/-/merge_requests/new?merge_request%5Bsource_branch%5D=xep-0308 but the URL is a 404
-
Ge0rG
(hijacking council to not disturb xsf@)
-
jonas’
editor@ would’ve been the right place to hijack
-
jonas’
are you logged in?
-
Ge0rG
no I'm not. thanks. So it's just a gitlab bug where it won't ask for login
-
jonas’
yes
-
pep.
there's a sign-in link on that page
-
pep.
but that could be made more obvious
-
daniel
Oh. It's Wednesday again. Time flies
-
jonas’
1) Roll Call
-
Zash
!
-
daniel
Hi
-
Ge0rG
good morning everyone!
-
jonas’
we have a tight agenda today, so let’s get right into it
-
jonas’
2) Agenda Bashing
-
Zash
dwd?
-
jonas’
Zash, assuming he’ll appear
-
dwd
Hello.
-
Zash
!
-
jonas’
I received suggestions from Ge0rG and dwd, respectively: - MR#22: XEP-0308: modernize LMC sending rules https://gitlab.com/xsf/xeps/-/merge_requests/22 - Proposed XMPP Extenison: Reactions https://xmpp.org/extensions/inbox/reactions.html
-
jonas’
I think we can safely add that to the Items for voting section
-
jonas’
any objections✎ -
jonas’
any objections? ✏
-
Zash
nah
-
Ge0rG
+1
-
daniel
No
-
dwd
No objections from me.
-
jonas’
excellent
-
jonas’
3) Editor’s Update - Accepted Compliance Suites 2021 as XEP-0443 (pipelines still running)
-
Ge0rG
thanks very much!
-
Ge0rG
daniel: you owe us an A/V section :)
-
jonas’
I didn’t send out the emails yet, because I fell asleep instead, but it’s there: https://xmpp.org/extensions/xep-0443.html
-
jonas’
moving on
-
jonas’
4) Items for voting
-
jonas’
4a) Handling of XEP-0393 The LC for XEP-0393 has expired a while ago and back then Council was not able to make a clear decision about how to proceed, given the discrepancies between the XEP, the ideal world, and the real world and given the lack of community consensus. Thus, we have a four-way vote for the next meeting where we try to find a solution, based on the previous ideas floating around in the community.
-
jonas’
soo... I’ve only made it a few more emails into the thread
-
jonas’
personally.
-
jonas’
Yet, I’d like to get this closed in one way or another.
-
Zash
From what I could gather, there was some agreement that it'd be fine if there was an opt-out (and maybe an opt-in). An opt-out was added.
-
daniel
My own preference is 'as is' 'move as is into informational'
-
daniel
In that order
-
jonas’
I tend to agree with daniel.
-
Ge0rG
I also agree with daniel's order.
-
Zash
'as is' or 'informational', no specific preference I think
-
jonas’
I personally still don’t like this thing, but I gather that there is value in it and in the same way it was phased in, we can phase it out at some point.
-
dwd
I think I broadly agree. The consensus is certainly not smooth - lost of outlying opinion - but it's there I think.
-
jonas’
I think we can’t put it into Informational as-is, because it defines wire format.
-
jonas’
any other points before I start to call the votes?
-
dwd
So for Draft as is, then?
-
jonas’
4a i) XEP-0393: Move to Informational
-
daniel
jonas’: if we call in the order outlined in the email that order of preference is not achievable
-
jonas’
daniel, that’s a good point
-
jonas’
we lack a voting scheme for multiple options with preference
-
jonas’
however, it won’t matter in this specific instance as I’m going to veto 4a i)
-
daniel
We can just flip the order
-
dwd
We do, but as all appeared to suggest we'd be OK with a advancing to Draft. So should we vote for that first and see?
-
daniel
To make it vote draft Frist
-
jonas’
yeah, let’s do that
-
daniel
And if that fails vote for informational
-
jonas’
/correct 4a i) XEP-0393: Accept as Draft
-
dwd
+1
-
jonas’
+0 to accepting XEP-0393 as draft standard
-
Ge0rG
+1 to accept XEP-0393 as draft
-
Zash
+1
-
daniel
+1
-
Zash
/joke /correct +0.999994
-
jonas’
cancelling all other votes on '393 then, because we have a way forward
-
jonas’
thanks
-
dwd
That was so much fun it's tempting to request a CFE next week.
-
Zash
no u
-
Ge0rG
I'm sure the yaxim implementation has some significant bugs, and then also fails to implement the MUST have feature.
-
jonas’
4b) MR#22: XEP-0308: modernize LMC sending URL: https://gitlab.com/xsf/xeps/-/merge_requests/22 Abstract: As discussed with Kev on xsf@ MUC today, it would be good to relax the requirements on the sending client in context of MUC, Carbons and MAM. Rendered-Version: https://ge0rg.gitlab.io/-/xeps/-/jobs/777236873/artifacts/rendered-changes/xep-0308.html
-
daniel
On list. I haven't seen that in time
-
Kev
(+1 on the vote I don't get as author)
-
Ge0rG
+1
-
Zash
+1
-
Ge0rG
there is a similar issue in 0333 btw.
-
dwd
I see the change in text, but what has actually changed?
-
jonas’
+1
-
Ge0rG
but 0333 is deferred anyway.
-
dwd
Oh, 280 and 313?
-
Kev
dwd: Previously it non-normatively suggested not sending if you don't know that everyone supports it. Now it suggests sending it but suggesting you let the user know it might look like a dupe.
-
Ge0rG
dwd: the old weasel words were against sending LMC when you are not 100% sure that the recipient will understand it. The new ones are in favor
-
Kev
It's entirely in (deliberately) non-normative language, so I think it's fine.
-
dwd
OK, but it also suggests a warning thing, and also provides '280 and '313 where the client cannot possibly ever know, so it's effectively requesting clients always have an "ARE YOU SURE Y/N" after every correction. Was that the intent?
-
Kev
I don't think it suggests a confirmation.
-
Kev
Merely that the user be made aware.
-
dwd
Well, it suggests a warning. But that will be needed every time.
-
jonas’
which would still be always
-
jonas’
dwd, could still be a notice on the first use of corrections, since it applies always
-
Kev
Swift has always done this, I believe, with a small message at the top while you're composing an edit letting you know some people might have it appear as a dupe, unless it looks like everyone supports it.
-
Zash
Something something UI/UX considerations in XEPs etc
-
Ge0rG
That message in swift, as reported by a user, was what made me look into the issue in the first place.
-
Kev
The old test already said that it suggests letting the user know in the way that Swift does, FWIW.✎ -
Kev
The old text already said that it suggests letting the user know in the way that Swift does, FWIW. ✏
-
daniel
(sorry getting real life interrupts here)
-
Kev
So the introduction of a suggested warning for the user is not new.
-
jonas’
The key difference is that the former weasel words said that "it is expected clients do not send corrections to unsupporting clients"
-
jonas’
while the new text says "Go ahead, but maybe warn the user✎ -
jonas’
while the new text says "Go ahead, but maybe warn the user" ✏
-
dwd
Yeah. I understand the desire here but it's basically saying "In some cases edits might not be supported. This is all cases. In those cases we suggest you warn a user." If you want to warn the user every time they use Edit, that's fine, but it's an odd phrasing.
-
Zash
I suppose you could word it more obviously as an implementation detail?
-
Kev
dwd: Fair.
-
Ge0rG
dwd: "in most IM setups"
-
jonas’
I agree that the wording could use a bit of polishing
-
Ge0rG
dwd: I'm sure there are XMPP deployments that don't do federation and have a fixed set of clients with known features.
-
jonas’
Ge0rG, would you take that on so that we can look at it again next week?
-
Ge0rG
jonas’: I've tried really hard to come up with a correct wording.
-
jonas’
ok, then let’s get this solved
-
dwd
Maybe just an "In almost all cases therefore, " is enough.
-
Ge0rG
It's probably not perfect, and I tried to keep as much of the original wording intact as possible, but I'm not sure how to make it better from where it is in the PR
-
dwd
Anyway, a vote - I guess +0 because I feel mean vetoing it.
-
Ge0rG
dwd: the sentence starts with "In most Instant Messaging environments"
-
Kev
As an aside if this were to lead to a material change to 308 please let me know because I'd like to take that opportunity to introduce a 'this is a fallback' payload that we could use universally.
-
dwd
But if you can reword that'd be awesome.
-
dwd
Kev, XEP-0428?
-
jonas’
How about s/but will make/but may make/;s/In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it/In most Instant Messaging situations (due to multiple resources and recipients receiving messages which are not seen when the message is being sent, for example due to &xep0313; or multi-session nicknames in &xep0045;), it/?✎ -
Kev
Apologies, missed that.
-
jonas’
How about: s/but will make/but may make/ s/In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it/In most Instant Messaging situations (due to multiple resources and recipients receiving messages which are not seen when the message is being sent, for example due to &xep0313; or multi-session nicknames in &xep0045;), it/? ✏
-
jonas’
still not quite readable, sorry
-
Ge0rG
jonas’: +1 for "s/but will make/but may make/"
-
jonas’
or maybe put the explanation which is currently in parenthesis in a separate paragraph, to make it less dense
-
jonas’
Ge0rG, could you update the wording in time for the next meeting?
-
Kev
(428 doesn't quite have the semantics I was looking for explicitly called out, but yes, that would do)
-
Ge0rG
jonas’: yes
-
jonas’
then we could move on to the next agenda item, which I expect also to take some time
-
jonas’
Ge0rG, thanks
-
jonas’
I retract my +1 then
-
jonas’
4c) Proposed XMPP Extension: Reactions URL: https://xmpp.org/extensions/inbox/reactions.html
-
Ge0rG
great, let's postpone to next week with next week's wording.
-
daniel
(sorry. I'm here for the next topic. But I'll have to catch up with history to vote on the current
-
daniel
Now former one
-
jonas’
dwd brought this up, there was a lot of discussions, Kev retro-retracted his -1 and changed it to -0✎ -
Kev
Not quite.
-
Kev
My original -1 was a -1.
-
Kev
I just think Council should, at this point, take the opportunity to not be beholden to my -1.
-
Zash
+1 for experimental then
-
jonas’
dwd brought this up, there was a lot of discussions, Kev said things about his vote ✏
-
Kev
All my original arguments stil stand.
-
jonas’
+1 for experimental, too
-
daniel
+1
-
jonas’
let’s get this into experimental, let them experiment with it, and be hard about the what’s and how’s when it moves to Draft
-
Zash
This ^
-
Kev
jonas’: I am 99% confident that won't happen, and it will become immovable, FWIW :)
-
jonas’
Kev, possible
-
dwd
We do, I think, need to solve the general problem - and I really don't want this going through to Draft without doing so - but +1.
-
daniel
Well if that's the case then it's just one more backward thing mam FC has to handle
-
dwd
jonas’, All the evidence so far is that there is no interest in finding consensus on this point.
-
daniel
It will already have to handle lmc and acks
-
daniel
*receipts
-
Ge0rG
+1 for Experimental
-
jonas’
thanks
-
jonas’
5) Date of next
-
dwd
daniel, Yes, but there's no point in trying to make FC anyway if we're just going to retrofit everything.
-
jonas’
next week *may* be tricky for me -- a kitchen will be in the process of being constructed here -- so I’m not 100% sure
-
jonas’
I hope it’s over by the time the council meeting happens and/or the disturbances will not prevent me from thinking that much
-
jonas’
I’ll prepare an agenda as usual though, so I am sure that someone will be able to chair spontaneously if necessary
-
Ge0rG
+1W WFM as of now
-
jonas’
in that sense: +1w "will work out in one way or another"
-
Zash
wfm, +1w
-
daniel
+1w wfm
-
dwd
I'll be here next week.
-
jonas’
excellent
-
jonas’
6) AOB
-
jonas’
Tedd brought up to me that we have a few XEPs stuck in Proposed state
-
jonas’
Just as a heads up, I intend to put all of them up for reconsideration next session
-
jonas’
XEP-0292 vCard4 Over XMPP XEP-0352 Client State Indication XEP-0353 Jingle Message Initiation XEP-0411 Bookmarks Conversion
-
Zash
:O
-
jonas’
(after an editor-side scan if anything was missed)
-
daniel
I have an AOB
- jonas’ hands the mic to daniel
-
daniel
Just quickly how does council feel about CFE'ing http upload?
-
daniel
If this is turning into a longer dabate I'm happy to do it next week tho
-
Zash
Which kind is that?
-
daniel
363
-
Zash
I mean CFE
-
jonas’
towards final
-
Kev
CFE is to Final
-
daniel
Moving it into final
-
jonas’
daniel, I’m all in for CFEing '363
-
daniel
I think I've never witnessed something going into final
-
Ge0rG
I don't see any issues with moving to final, but I also only have straight-forward deployments, no fancy authenticated S3 buckets
-
daniel
I'm not even sure how the process looks exactly
-
jonas’
note that CFE is started by the editor only
-
daniel
Oh ok
-
dwd
daniel, To be honest, I'd like to get the OOB stuff moved on. '363 is broadly fine, I think, but without the other parts I worry we don't really have the experience for Final.
-
dwd
daniel, I mean, OOB if that's what people use to actually hand over the file URL to the other party.
-
Ge0rG
dwd: what would be the way forward? Replace the unstandardized OOB use with SIMS?
-
jonas’
ok, this *is* getting out of hand
-
Ge0rG
we can continue that off-meeting
-
dwd
Ge0rG, Or define what the unstandardized OOB thing *is*.
-
daniel
Literally oob or something that replaces oob?
-
daniel
> ok, this *is* getting out of hand OK. Can we put it on next week's agenda
-
jonas’
sure
-
dwd
daniel, I have no horse in this particular race, so I don't mind.
-
jonas’
Any other AOB?
-
Zash
I don't recall what happened with OOB
-
daniel
i have thoughts. but i can keep them until after the meeting
-
dwd
daniel, But if I were to have a horse in the race, it'd be one that somehow combined HTTP Upload with Jingle-FT to support other more limited environments. But that's probably wishful whimsy, and definitely not a hill for me to die on, or even climb merely to look at the view, to be honest.
-
daniel
on OOB that is
-
jonas’
ok assuming no AOB
-
jonas’
8) Ite Meeting Est
-
jonas’
Thanks for the Minutes and the "Proposed" heads up to Tedd, thanks to everyone for everything
-
dwd
jonas’, Thanks.
-
Zash
thanks
-
jonas’
also, please move OOB etc. to xsf@
-
Ge0rG
thanks jonas’
-
jonas’
thank you for that, too :)
-
daniel
Ge0rG, I finished my move (mostly) and I will probably have more time starting next week
-
daniel
wrt compliance
-
jonas’
\o/
-
Ge0rG
daniel: cool!