XMPP Council - 2023-04-12

it's time

good morning everyone!

1) roll call

o/

I'm finally back

👋️

moparisthebest?

ah he said last week that he wont be here I think

2) Agenda bashing

nothing to bash

3) Editors update

I don’t have one this week but i'll try to compose a list for next week now that the list is working again

4) Items for voting

a) Proposed Extension: SASL Upgrade Tasks https://xmpp.org/extensions/inbox/xep-scram-upgrade.html

+1

I'm quite lacking in SCRAM things, but this looks good from a brief review, so +1

Be aware that the lists are not 100% working at the moment. Archives liable to not be there etc.

+1

I guess it's good enough to start with, even though I think there are some issues with it, so +1

b) XEP-0198: Add section defining SASL2 and BIND2 interaction https://github.com/xsf/xeps/pull/1215

+1

This is still blocked by advancement of BIND2?

+1

it was previously blocked by bind 2 not being published. whether or not it should be blocked by bind 2 not being stable is up for debate

+1

i'm leaning towards 'no' hence my +1 vote

I can get behind that

I'm confused because 90% of that PR is already in 0386?

is it?

i think that's just examples not normative

e.g. "Note: If the client included a <resume/> element in its SASL2 negotiation, that MUST be processed first by the server. If that resumption is successful, the server MUST skip resource binding (a resumed session already has a resource bound) and MUST entirely ignore the <bind/> request."

same sentence in both XEPs

maybe we forgot to remove them from bind 2... ?

i just remember that council was asked do you want this in bind 2 or in SM or in a new xep and we said we want this in SM

there's also at least one thing that's probably wrong in the PR "the server adds a <feature/> element in the namespace "urn:xmpp:sm:3" into the <inline/> element of BIND2 which is sent in the stream features" -> bind 2 uses "<feature var="urn:xmpp:sm:3" />", no namespace here

it's "just" wording, but I don't like adding wrong wording to a stable XEP

that’s fair.

do you want to veto until this is fixed?

well, I guess that's because I created the XEP when BIND2 syntax wasn't stable yet

yes, I'll go through the PR and see if there are other issues

*XEP=PR

but generally speaking do we still agree that this belongs into SM?

and then let tmolitor know 🙂

larma, sure :)

and by extension that duplicate bits from bind 2 should probably be removed?

removed where? in bind2 or in 0198?

ok I'm recording a -1 for now (just so it doesn’t expire and goes through accidentially)

daniel, yes, thanks

i meant removed from bind2

but it was framed as a question

yes, I would remove it from bind2 and have sm only show up in bind2 in examples, but not beyond that

ok. let's move on then

c) Reconsider 'Proposed Extension: Content Types in Messages' https://xmpp.org/extensions/inbox/content-types.html

+1

personally i'm not a fan. but that shouldn’t stop it from being a XEP

What's the normative action behind "reconsider"? A new last call?

MattJ: can you update bind2 accordingly?

we are voting to accept it as experimental

it is in inbox

Ge0rG, think of it as being resubmitted as protoxep

+1 then

I think the main reason to -1 it would be if it was considered actively harmful to adopt (which original Council did consider), or if nothing has changed in the interim.

I've very mixed feeling on this one. I'm +1 because I don't want to block something from experimental that fits the formal requirements, but I have high doubts that this will be good for the ecosystem and I already fear people sending around markdown in various incompatible flavors arguing that it's "supported" by this XEP ✏

I share the concerns of larma

I haven't looked to see if there's anything in procedure that would prevent future Councils accepting what was previously rejected.

also the text/xml encoding example in there gives me headaches

What's the original author's stance?

They liked it then and they still like it now.

i don’t think "fits the ecosystem" is something that matters at this stage

i think that's a question that will come up in last call

> i don’t think "fits the ecosystem" is something that matters at this stage I think "not actively harmful to the ecosystem" is almost the only thing that matters at this stage.

Can we instantly issue a last call and then reject it? 😀

Was that a serious procedural question?

No

But if it was proposed for last call now, I would vote to reject and I don't see how this can be changed without fundamentally changing the idea of the XEP

larma: I think the procedural difference is that the community gets a chance to discuss it, and to convince you of its importance

I'm +1.

Well, if one entirely removed the alternative encodings I'd probably be fine with it

Even though this may not be fully useful or even good for messaging contexts, I guess it makes sense to have something like this at least for pubsub use-cases (atom).

fwiw I think the author specifically wanted those

Actually, you can just do content type multipart/alternative then 😉

> I would like to re-introduce this proposal for publication as an experimental XEP. More and more use Markdown (as an example). While there are objections by some to use Markdown, the purpose of the XEP is not to force those that do not want to use Markdown, to use it, but to allow those that want to send Markdown with a common way to do it, without just sending it as plain text (as many do). The extension is not focused on Markdown, but tries to solve the more general problem on how to send content, regardless of format, in a way that is understandable by those that support that format, as well as those that don’t. It reuses the common content types available in other protocols on the Internet to do so, so the pattern is well known and works in other non-XMPP-based protocols.

because multiple contents is one of the main points the previous council complain about too

(From Peter Waher)

jonas’, Atom already has this, all three elements of title, summary and content can be either plain text, &lt;-encoded HTML, or embedded XHTML.

I'd like to point out that RFC 7763 has a specific section to mention that markdown should not be used for publishing, but only for writing and editing. If one wants to use markdown in XMPP, the "correct" way to do so would be to convert it to (X)HTML before sending

daniel, please record a 0 for me

we are technically running over but we have 2 more items to vote on. is everyone ok by extending this meeting by 15-20 mins?

fine by me

Ge0rG, jonas’ are you still here or should we continue next week?

I'm sorry I had to get on an urgent call and am afk

OK. I’ll move the remaining two items to next week

Pending votes

i’m going to quickly take the chance to vote on publish_node_full +1

I am still here

sorry

do you have a link to pubsub node full please?

https://github.com/xsf/xeps/pull/1275

also, I'd like to join larma in a +0 on the content type thing, I think that more appropriately reflects what I think of it

https://github.com/xsf/xeps/pull/1275 <= that's from two weeks ago and you voted +1

ah great :)

jonas’, I've changed your vote

anyway

6) Date of next

+1w wfm

+1w wfm

I'm travelling next week, but will likely be able to make it nonetheless

larma, noted

7) AOB

please note that we are already over time so unless it's urgent just tell me to put it on the agenda for next week

ok assuming nothing urgent then

8) Close

Thanks all

Thanks daniel

Thanks daniel