Ge0rGjonas’: I've pushed a new branch to gitlab, and got this on the shell:
remote: To create a merge request for xep-0308, visit:
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?
Ge0rGno I'm not. thanks. So it's just a gitlab bug where it won't ask for login
pep.there's a sign-in link on that page
pep.but that could be made more obvious
danielOh. It's Wednesday again. Time flies
jonas’1) Roll Call
Ge0rGgood morning everyone!
jonas’we have a tight agenda today, so let’s get right into it
jonas’2) Agenda Bashing
jonas’Zash, assuming he’ll appear
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
dwdNo objections from me.
jonas’3) Editor’s Update
- Accepted Compliance Suites 2021 as XEP-0443 (pipelines still running)
Ge0rGthanks very much!
Ge0rGdaniel: 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’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
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’Yet, I’d like to get this closed in one way or another.
ZashFrom 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.
danielMy own preference is 'as is' 'move as is into informational'
danielIn that order
jonas’I tend to agree with daniel.
Ge0rGI 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.
dwdI 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?
dwdSo for Draft as is, then?
jonas’4a i) XEP-0393: Move to Informational
danieljonas’: 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)
danielWe can just flip the order
dwdWe 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?
danielTo make it vote draft Frist
jonas’yeah, let’s do that
danielAnd if that fails vote for informational
jonas’/correct 4a i) XEP-0393: Accept as Draft
jonas’+0 to accepting XEP-0393 as draft standard
Ge0rG+1 to accept XEP-0393 as draft
Zash/joke /correct +0.999994
jonas’cancelling all other votes on '393 then, because we have a way forward
dwdThat was so much fun it's tempting to request a CFE next week.
Ge0rGI'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
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.
danielOn list. I haven't seen that in time
Kev(+1 on the vote I don't get as author)
Ge0rGthere is a similar issue in 0333 btw.
dwdI see the change in text, but what has actually changed?
Ge0rGbut 0333 is deferred anyway.
dwdOh, 280 and 313?
Kevdwd: 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.
Ge0rGdwd: 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
KevIt's entirely in (deliberately) non-normative language, so I think it's fine.
dwdOK, 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?
KevI don't think it suggests a confirmation.
KevMerely that the user be made aware.
dwdWell, 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
KevSwift 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.
ZashSomething something UI/UX considerations in XEPs etc
Ge0rGThat message in swift, as reported by a user, was what made me look into the issue in the first place.
KevThe old test already said that it suggests letting the user know in the way that Swift does, FWIW.
KevThe 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)
KevSo 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"
dwdYeah. 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.
ZashI suppose you could word it more obviously as an implementation detail?
Ge0rGdwd: "in most IM setups"
jonas’I agree that the wording could use a bit of polishing
Ge0rGdwd: 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?
Ge0rGjonas’: I've tried really hard to come up with a correct wording.
jonas’ok, then let’s get this solved
dwdMaybe just an "In almost all cases therefore, " is enough.
Ge0rGIt'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
dwdAnyway, a vote - I guess +0 because I feel mean vetoing it.
Ge0rGdwd: the sentence starts with "In most Instant Messaging environments"
KevAs 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.
dwdBut if you can reword that'd be awesome.
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/?
KevApologies, missed that.
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
Ge0rGjonas’: +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)
jonas’then we could move on to the next agenda item, which I expect also to take some time
Ge0rGgreat, 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
danielNow former one
jonas’dwd brought this up, there was a lot of discussions, Kev retro-retracted his -1 and changed it to -0
KevMy original -1 was a -1.
KevI 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
KevAll my original arguments stil stand.
jonas’+1 for experimental, too
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
Kevjonas’: I am 99% confident that won't happen, and it will become immovable, FWIW :)
dwdWe 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.
danielWell if that's the case then it's just one more backward thing mam FC has to handle
dwdjonas’, All the evidence so far is that there is no interest in finding consensus on this point.
danielIt will already have to handle lmc and acks
Ge0rG+1 for Experimental
jonas’5) Date of next
dwddaniel, 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"
dwdI'll be here next week.
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
jonas’(after an editor-side scan if anything was missed)
danielI have an AOB
jonas’hands the mic to daniel
danielJust quickly how does council feel about CFE'ing http upload?
danielIf this is turning into a longer dabate I'm happy to do it next week tho
ZashWhich kind is that?
ZashI mean CFE
KevCFE is to Final
danielMoving it into final
jonas’daniel, I’m all in for CFEing '363
danielI think I've never witnessed something going into final
Ge0rGI don't see any issues with moving to final, but I also only have straight-forward deployments, no fancy authenticated S3 buckets
danielI'm not even sure how the process looks exactly
jonas’note that CFE is started by the editor only
dwddaniel, 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.
dwddaniel, I mean, OOB if that's what people use to actually hand over the file URL to the other party.
Ge0rGdwd: what would be the way forward? Replace the unstandardized OOB use with SIMS?
jonas’ok, this *is* getting out of hand
Ge0rGwe can continue that off-meeting
dwdGe0rG, Or define what the unstandardized OOB thing *is*.
danielLiterally oob or something that replaces oob?
daniel> ok, this *is* getting out of hand
OK. Can we put it on next week's agenda
dwddaniel, I have no horse in this particular race, so I don't mind.
jonas’Any other AOB?
ZashI don't recall what happened with OOB
danieli have thoughts. but i can keep them until after the meeting
dwddaniel, 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.
danielon 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
jonas’also, please move OOB etc. to xsf@
jonas’thank you for that, too :)
danielGe0rG, I finished my move (mostly) and I will probably have more time starting next week