XMPP Council - 2020-10-07

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

(hijacking council to not disturb xsf@)

editor@ would’ve been the right place to hijack

are you logged in?

no I'm not. thanks. So it's just a gitlab bug where it won't ask for login

yes

there's a sign-in link on that page

but that could be made more obvious

Oh. It's Wednesday again. Time flies

1) Roll Call

!

Hi

good morning everyone!

we have a tight agenda today, so let’s get right into it

2) Agenda Bashing

dwd?

Zash, assuming he’ll appear

Hello.

!

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

I think we can safely add that to the Items for voting section

any objections? ✏

nah

+1

No

No objections from me.

excellent

3) Editor’s Update - Accepted Compliance Suites 2021 as XEP-0443 (pipelines still running)

thanks very much!

daniel: you owe us an A/V section :)

I didn’t send out the emails yet, because I fell asleep instead, but it’s there: https://xmpp.org/extensions/xep-0443.html

moving on

4) Items for voting

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.

soo... I’ve only made it a few more emails into the thread

personally.

Yet, I’d like to get this closed in one way or another.

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.

My own preference is 'as is' 'move as is into informational'

In that order

I tend to agree with daniel.

I also agree with daniel's order.

'as is' or 'informational', no specific preference I think

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.

I think I broadly agree. The consensus is certainly not smooth - lost of outlying opinion - but it's there I think.

I think we can’t put it into Informational as-is, because it defines wire format.

any other points before I start to call the votes?

So for Draft as is, then?

4a i) XEP-0393: Move to Informational

jonas’: if we call in the order outlined in the email that order of preference is not achievable

daniel, that’s a good point

we lack a voting scheme for multiple options with preference

however, it won’t matter in this specific instance as I’m going to veto 4a i)

We can just flip the order

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?

To make it vote draft Frist

yeah, let’s do that

And if that fails vote for informational

/correct 4a i) XEP-0393: Accept as Draft

+1

+0 to accepting XEP-0393 as draft standard

+1 to accept XEP-0393 as draft

+1

+1

/joke /correct +0.999994

cancelling all other votes on '393 then, because we have a way forward

thanks

That was so much fun it's tempting to request a CFE next week.

no u

I'm sure the yaxim implementation has some significant bugs, and then also fails to implement the MUST have feature.

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

On list. I haven't seen that in time

(+1 on the vote I don't get as author)

+1

+1

there is a similar issue in 0333 btw.

I see the change in text, but what has actually changed?

+1

but 0333 is deferred anyway.

Oh, 280 and 313?

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.

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

It's entirely in (deliberately) non-normative language, so I think it's fine.

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?

I don't think it suggests a confirmation.

Merely that the user be made aware.

Well, it suggests a warning. But that will be needed every time.

which would still be always

dwd, could still be a notice on the first use of corrections, since it applies always

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.

Something something UI/UX considerations in XEPs etc

That message in swift, as reported by a user, was what made me look into the issue in the first place.

The old text already said that it suggests letting the user know in the way that Swift does, FWIW. ✏

(sorry getting real life interrupts here)

So the introduction of a suggested warning for the user is not new.

The key difference is that the former weasel words said that "it is expected clients do not send corrections to unsupporting clients"

while the new text says "Go ahead, but maybe warn the user" ✏

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.

I suppose you could word it more obviously as an implementation detail?

dwd: Fair.

dwd: "in most IM setups"

I agree that the wording could use a bit of polishing

dwd: I'm sure there are XMPP deployments that don't do federation and have a fixed set of clients with known features.

Ge0rG, would you take that on so that we can look at it again next week?

jonas’: I've tried really hard to come up with a correct wording.

ok, then let’s get this solved

Maybe just an "In almost all cases therefore, " is enough.

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

Anyway, a vote - I guess +0 because I feel mean vetoing it.

dwd: the sentence starts with "In most Instant Messaging environments"

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.

But if you can reword that'd be awesome.

Kev, XEP-0428?

Apologies, missed that.

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/? ✏

still not quite readable, sorry

jonas’: +1 for "s/but will make/but may make/"

or maybe put the explanation which is currently in parenthesis in a separate paragraph, to make it less dense

Ge0rG, could you update the wording in time for the next meeting?

(428 doesn't quite have the semantics I was looking for explicitly called out, but yes, that would do)

jonas’: yes

then we could move on to the next agenda item, which I expect also to take some time

Ge0rG, thanks

I retract my +1 then

4c) Proposed XMPP Extension: Reactions URL: https://xmpp.org/extensions/inbox/reactions.html

great, let's postpone to next week with next week's wording.

(sorry. I'm here for the next topic. But I'll have to catch up with history to vote on the current

Now former one

Not quite.

My original -1 was a -1.

I just think Council should, at this point, take the opportunity to not be beholden to my -1.

+1 for experimental then

dwd brought this up, there was a lot of discussions, Kev said things about his vote ✏

All my original arguments stil stand.

+1 for experimental, too

+1

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

This ^

jonas’: I am 99% confident that won't happen, and it will become immovable, FWIW :)

Kev, possible

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.

Well if that's the case then it's just one more backward thing mam FC has to handle

jonas’, All the evidence so far is that there is no interest in finding consensus on this point.

It will already have to handle lmc and acks

*receipts

+1 for Experimental

thanks

5) Date of next

daniel, Yes, but there's no point in trying to make FC anyway if we're just going to retrofit everything.

next week *may* be tricky for me -- a kitchen will be in the process of being constructed here -- so I’m not 100% sure

I hope it’s over by the time the council meeting happens and/or the disturbances will not prevent me from thinking that much

I’ll prepare an agenda as usual though, so I am sure that someone will be able to chair spontaneously if necessary

+1W WFM as of now

in that sense: +1w "will work out in one way or another"

wfm, +1w

+1w wfm

I'll be here next week.

excellent

6) AOB

Tedd brought up to me that we have a few XEPs stuck in Proposed state

Just as a heads up, I intend to put all of them up for reconsideration next session

XEP-0292 vCard4 Over XMPP XEP-0352 Client State Indication XEP-0353 Jingle Message Initiation XEP-0411 Bookmarks Conversion

:O

(after an editor-side scan if anything was missed)

I have an AOB

Just quickly how does council feel about CFE'ing http upload?

If this is turning into a longer dabate I'm happy to do it next week tho

Which kind is that?

363

I mean CFE

towards final

CFE is to Final

Moving it into final

daniel, I’m all in for CFEing '363

I think I've never witnessed something going into final

I don't see any issues with moving to final, but I also only have straight-forward deployments, no fancy authenticated S3 buckets

I'm not even sure how the process looks exactly

note that CFE is started by the editor only

Oh ok

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.

daniel, I mean, OOB if that's what people use to actually hand over the file URL to the other party.

dwd: what would be the way forward? Replace the unstandardized OOB use with SIMS?

ok, this *is* getting out of hand

we can continue that off-meeting

Ge0rG, Or define what the unstandardized OOB thing *is*.

Literally oob or something that replaces oob?

> ok, this *is* getting out of hand OK. Can we put it on next week's agenda

sure

daniel, I have no horse in this particular race, so I don't mind.

Any other AOB?

I don't recall what happened with OOB

i have thoughts. but i can keep them until after the meeting

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.

on OOB that is

ok assuming no AOB

8) Ite Meeting Est

Thanks for the Minutes and the "Proposed" heads up to Tedd, thanks to everyone for everything

jonas’, Thanks.

thanks

also, please move OOB etc. to xsf@

thanks jonas’

thank you for that, too :)

Ge0rG, I finished my move (mostly) and I will probably have more time starting next week

wrt compliance

\o/

daniel: cool!