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
daniel
4) Items for voting
daniel
a) Proposed Extension: SASL Upgrade Tasks
https://xmpp.org/extensions/inbox/xep-scram-upgrade.html
daniel
+1
Ge0rG
I'm quite lacking in SCRAM things, but this looks good from a brief review, so +1
Kev
Be aware that the lists are not 100% working at the moment. Archives liable to not be there etc.
jonas’
+1
larma
I guess it's good enough to start with, even though I think there are some issues with it, so +1
daniel
b) XEP-0198: Add section defining SASL2 and BIND2 interaction
https://github.com/xsf/xeps/pull/1215
daniel
+1
Ge0rG
This is still blocked by advancement of BIND2?
jonas’
+1
Tobiashas left
Tobiashas joined
daniel
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
Ge0rG
+1
daniel
i'm leaning towards 'no' hence my +1 vote
Ge0rG
I can get behind that
larma
I'm confused because 90% of that PR is already in 0386?
daniel
is it?
daniel
i think that's just examples not normative
larma
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."
larma
same sentence in both XEPs
daniel
maybe we forgot to remove them from bind 2... ?
daniel
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
larma
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
larma
it's "just" wording, but I don't like adding wrong wording to a stable XEP
daniel
that’s fair.
daniel
do you want to veto until this is fixed?
tmolitor
well, I guess that's because I created the XEP when BIND2 syntax wasn't stable yet
larma
yes, I'll go through the PR and see if there are other issues
tmolitor
*XEP=PR
daniel
but generally speaking do we still agree that this belongs into SM?
larma
and then let tmolitor know 🙂
tmolitor
larma, sure :)
daniel
and by extension that duplicate bits from bind 2 should probably be removed?
stpeterhas left
tmolitor
removed where? in bind2 or in 0198?
daniel
ok I'm recording a -1 for now (just so it doesn’t expire and goes through accidentially)
larma
daniel, yes, thanks
daniel
i meant removed from bind2
daniel
but it was framed as a question
larma
yes, I would remove it from bind2 and have sm only show up in bind2 in examples, but not beyond that
daniel
ok. let's move on then
daniel
c) Reconsider 'Proposed Extension: Content Types in Messages'
https://xmpp.org/extensions/inbox/content-types.html
daniel
+1
daniel
personally i'm not a fan. but that shouldn’t stop it from being a XEP
Ge0rG
What's the normative action behind "reconsider"? A new last call?
tmolitor
MattJ: can you update bind2 accordingly?
daniel
we are voting to accept it as experimental
daniel
it is in inbox
larma
Ge0rG, think of it as being resubmitted as protoxep
Ge0rG
+1 then
Kev
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.
larma
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✎
larma
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 ✏
jonas’
I share the concerns of larma
Kev
I haven't looked to see if there's anything in procedure that would prevent future Councils accepting what was previously rejected.
jonas’
also the text/xml encoding example in there gives me headaches
Ge0rG
What's the original author's stance?
Kev
They liked it then and they still like it now.
daniel
i don’t think "fits the ecosystem" is something that matters at this stage
daniel
i think that's a question that will come up in last call
Kev
> 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.
larma
Can we instantly issue a last call and then reject it? 😀
Kev
Was that a serious procedural question?
larma
No
larma
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
Ge0rG
larma: I think the procedural difference is that the community gets a chance to discuss it, and to convince you of its importance
jonas’
I'm +1.
larma
Well, if one entirely removed the alternative encodings I'd probably be fine with it
jonas’
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).
daniel
fwiw I think the author specifically wanted those
larma
Actually, you can just do content type multipart/alternative then 😉
Kev
> 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.
👍️ 1
daniel
because multiple contents is one of the main points the previous council complain about too
Kev
(From Peter Waher)
Link Mauve
jonas’, Atom already has this, all three elements of title, summary and content can be either plain text, <-encoded HTML, or embedded XHTML.
larma
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
larma
daniel, please record a 0 for me
daniel
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?
larma
fine by me
vanitasvitae_has left
vanitasvitae_has joined
daniel
Ge0rG, jonas’ are you still here or should we continue next week?
Ge0rG
I'm sorry I had to get on an urgent call and am afk
daniel
OK. I’ll move the remaining two items to next week
👍️ 1
daniel
Pending votes
daniel
i’m going to quickly take the chance to vote on publish_node_full +1
jonas’
I am still here
jonas’
sorry
jonas’
do you have a link to pubsub node full please?
larma
https://github.com/xsf/xeps/pull/1275
jonas’
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
daniel
https://github.com/xsf/xeps/pull/1275 <= that's from two weeks ago and you voted +1
jonas’
ah great :)
daniel
jonas’, I've changed your vote
daniel
anyway
daniel
6) Date of next
daniel
+1w wfm
jonas’
+1w wfm
larma
I'm travelling next week, but will likely be able to make it nonetheless
daniel
larma, noted
daniel
7) AOB
daniel
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