dwdSorry, on 4G with conversations and it was trying to join the MUC with an disconnected account.
danieloh. yes i'm here
danielforgot that it's wednesday again
Tobias2) Minute taker
dwdI can't I'm afraid; on a tablet and it's not very easy to multitask.
SamWhiteddaniel: it's Wednesday every week at this time
Tobias3) Vote on accepting https://github.com/xsf/xeps/pull/528 " XEP-0071: make security considations much clearer #528 "
Link Mauve+1, there are other things I want to add next but it already is a net improvement.
Tobias4) Vote on accepting ProtoXEP: Body Markup Hints https://xmpp.org/extensions/inbox/bmh.html
TobiasI'll vote on list
dwdI'd like to see how the discussion goes on this one.
TobiasI'll interpret that as 'on list' :)
Link MauveI’ve already read it yesterday evening, and I’m very much -1 on it due to the concept of waiving any format support, forcing implementations to support multiple formats and making it impossible for a message to carry more than one (think MUC for example).
dwdYou can interpret it as not voting yet, indeed.
danieli'm not a huge fan of the XEP personally but technically it looks fine. so +1 from me
SamWhitedI'm very much waivering somewhere between Link Mauve and daniel's positions, so on list for me (though it might not matter if Link Mauve is -1)
Link Mauve(My -1 might change, but not with the XEP as is.)
Ge0rGLink Mauve: is "very much -1" a -1 vote?
Link MauveYes. :)
dwdI'd appreciate a debate on list about this, mind - I'd like to explore how we might change your mind.
Tobias5) Vote on accepting ProtoXEP: Atomically Compare-And-Publish PubSub Items https://xmpp.org/extensions/inbox/cap.html
TobiasI'm on list on this too
dwdI've not had a chance to review this properly yet, so I'll vote on list later.
Link Mauvedwd, sure, but it’s already been mostly summarised in the long XHTML-IM thread, which I also read last night.
dwdBad luck. :-)
Link MauveTobias, on list too.
SamWhitedThere are a few things I don't love about this one, but I think having the operation is useful and it's a good start.
dwdI think I'm +1 on this, given Paul's implemented it so the real errors are probably in spec not fundamental.
TobiasThe rest I think is pending external events or further discussion. Will ping respective people afterwards.
Tobias7) Date of next
Tobiassame time next week
SamWhitedWhat about obsoleting XHTML-IM? I know that's the controversial one, but it seems like the discussion has moved on to "what to do next"
SamWhitedSo I don't see any reason to hold off obsoleting it and indicating that we want to do formatting-nextgen
jonaswI mentioned one
jonaswbut you might disregard it of course
danieli haven't had time to read through the thread
TobiasSamWhited, we just started the discussion a week ago, i suggest waiting for next week to vote on obsoleting it
Link MauveSamWhited, jonasw’s email was very detailed about why we shouldn’t do that without a path forward.
I am still not keen on obsoleting XHTML-IM before we have an actual
alternative ready. I don’t think that this will achieve anything good.
Instead, I think that one of two things will happen:
(a) Clients continue to implement XHTML-IM because it is the only actual
way to convey markup right now (this is what I’ll do until there’s a
(b) The ecosystem will fracture in islands of different, underspecified,
plain-text markups put in <body/>.
I don’t think either is particularly good. I also wonder what it would look
like to have the only markup protocol with actual deployment being obsoleted
:-) (*hint towards the general direction of the Experimental vs. Draft
Tobiaslike daniel, i haven't read all the mails in that thread yet
dwdYeah, I think people have raised objections largely predicated on "what else would we do", though. So I don't think there's community consensus just yet; this despite my feeling that we should deprecate it.
SamWhitedLet's discuss next week then
Tobiasso time for next, as usual
dwdAOB - I noticed the email from Klaus; we should probably consider that *before* someone demonstrates the problem...
dwdPerhaps simply [re]confirming votes on list in this room would be enough?
Link MauveWhile making sure we are using our usual JID?
SamWhitedSounds like premature optimization. I can't imagine that it ever becomes a problem, and even if it did it would be pretty easy for someone to see it and say "wait, I didn't send that"
TobiasReminder for daniel to to vote in the "[Council] 2017-09-27 XSF Council Minutes" thread on accepting "XEP-0060: Add pubsub#multi-items in Publish-Subscribe features #500"
Link MauveSamWhited, that was the answer I was going to make after this meeting, that we should be aware of the emails “we” send.
Tobias+1 on what SamWhited said
Link MauveBasically monitor the mailing list.
Link MauveOh, and only us can post to council@, correct?
dwdThat may well be sufficient, too.
jonaswSamWhited, given that nobody reads all emails on list, I find that a not-so-good solution.
jonaswGPG would be nice
KevLink Mauve: Yes, and thankfully email can't be forged ;)
dwdYes, but that means anyone using your email address.
Kevjonasw: Council do, though, that's kinda the point.
jonaswKev, okay, if you say so :)
Link MauveKev, do you mean the ML software isn’t checking my server is actually who it pretends to be? :(
dwdGood luck with finding a standard for that.
Link Mauvejonasw, I make a point in reading everything, even if I don’t always answer.
Kevdmarc will solve everything.
jonaswLink Mauve, how would it? :)
jonaswSPF would be an option, sure...
KevBut yes, I think that's the worst bit of being on Council, the responsibility to process every single blasted mail.
jonaswemail is a mess.
jonaswKev, didn’t know that it was a requirement.
Tobiasanother point for AOB, Ge0rG's very old PR https://github.com/xsf/xeps/pull/434, it still says "Needs list discussion". Ge0rG, is that still correct?
Ge0rGTobias: Hints was -1ed, so that PR is in limbo
Link MauveGe0rG, would it get unblocked by your suggestion of better semantic hints?
Ge0rGTobias: I'd like to hear if the council is +1 on the proposed wording change, to make the rules stricter
KevI'm still -1 on enforcing the rules, FWIW.
Ge0rGKev: what would make you change your mind?
KevGe0rG: Having the big picture clear and agreed first.
jonaswI think by the way that we urgently and before advancing MAM&CSI need to have a discussion about the point georg brought up about message routing.
Ge0rGKev: so I should continue with my TLDR posts?
Link MauveI want to take part into that big whiteboard routing party, where do I sign?
TobiasTLDR is always nice
KevGe0rG: Absolutely. And I should read the one you sent the other day.
Ge0rGKev: that's not very motivating.
SamWhitedI agree, I like the idea of clarifying the rules, but I think it needs a bit whiteboarding party first. I don't have confidence that this is necessarily the correct set of rules.
KevI promise I'm going to, if that helps. But, busy week.
jonaswI’m all in for whiteboarding, if I can attend somehow :)
Tobiasok..any further AOB topics?
Tobiasdoesn't look like it
Tobiasbangs the gavel
SamWhited*whew* busy meeting; thanks all!
Tobiasthanks Ge0rG for taking notes
Link MauveThanks all. :)
Tobiasplease send them to standards@ and council@
FlowLink Mauve, "waiving any format support"?
Tobiasbtw: people interesting in serving on council, please add at https://wiki.xmpp.org/web/Board_and_Council_Elections_2017
jonaswis nobody gonna re-apply?
Link MauveFlow, just like 0380, you are making an incomplete list of supported formats, clients are free to pick any of them (as long as there is disco, otherwise it’s outright impossible), and there is nothing required to be supported.
Tobiasjonasw, probably people are too busy and haven't added them yet
jonaswdisco doesn’t work, I should’ve added that
jonasw(to my email on that protoxep)
Link Mauve<body-markup-hint language="text/html"/> is totally fine, as an example.
jonaswoh the pain
FlowLink Mauve, I don't think the situation is comperable to xep380
Link Mauveshivers in horror, remembering Adium’s OTR <FONT>…
jonaswthat sounds so much like things libpurple would do.
Link Mauvejonasw, Tobias, it isn’t the day before the deadline, nobody has even started working on their application. :p
FlowSo, the situation I'm is that I've data which is formated using CommonMark. And I want to send that data to an XMPP client. I don't want to make the effor to write a CommonMark to XHTML-IM-NEXT convert, so I just shove it into the <body/>
jonaswI find that a super bad idea
jonaswyou shouldn’t be doing that in the first place
FlowAnd all I want to achieve with BMH is to tell the receiving entity: Hey, there is CommonMark in the <body/>
Link MauveFlow, not making the effort of using a library to generate a common format that everyone understands is a very bad practice, imo.
Flowjonasw, but I will do that, and others will also
jonasweither you care about interop (and use a separat element + plaintext variant in <body/>), or you don’t
jonaswtacking a "greenwashing" "oh and if you happen to support my unspecified format, this is it" tag doesn’t make things a whole lot better
Link MauveIf you consider that CommonMark to be the plain-text alternative of the XHTML-IM version, you can put it in the body already, but please don’t assume the recipient will also need to support CommonMark.
FlowI think <body/> is the highest level of interop
jonaswputting markup in <body/> isn’t
FlowSo I do care very much
Link MauveYes, I agree on that.
Link Mauvejonasw, exactly.
FlowLink Mauve, I don't assume that
Flowbut I give him a hint that it's CommonMark
jonaswputting marked-up things in body could easily break accessibility tools
Link MauveFlow, if my client doesn’t support CommonMark but reST, will you convert that for me?
jonaswFWIW, I’ve heard "there are no accessible clients for jabber" more than once as a reason not to use it.
FlowLink Mauve, If the data I have is already formated in CommonMark, possibly not
jonaswwhile many of the hip messengers in fact are quite accessible.
Link MauveIf you are talking to me and my friend there whose client only supports Creole, in a MUC, are you going to provide us two different messages?
FlowI feel like the XEP would had more acceptance if there was no disco part
jonaswthe disco part is irrelevant, because it doesn’t work
FlowLink Mauve, that's another aspect
jonaswit doesn’t work in MUC, it doesn’t work in MIX, it doesn’t work in modern one-on-one chats due to carbons and MAM
Link MauveFlow, all that just because you couldn’t find a library to generate XHTML-IM from your CommonMark?
jonasw(also, shouldn’t we move this discussion to xsf@?)
KevGe0rG: Because I'd hate to demotivate you.
Link Mauve(I’m some 2000+ lines up in that buffer, I have a lot of backlog to read before that discussion then. :x)
Link Mauve(Damn being ill!)
Ge0rGSorry, I just got a bunch of work calls. Now working up the AOBs.
Ge0rGdwd: what's the context of "dwd> AOB - I noticed the email from Klaus; we should probably consider that *before* someone demonstrates the problem..."?
KevGe0rG: Voting on list without sender verification.
Ge0rGcan I write that into the Minutes?
KevIt was an AOB, yes.
SamWhitedI am writing up a reply to the thing Link Mauve suggested hadn't been addressed (jonasw's email), FYI. It will be on list shortly. I think I've addressed all these points individually, but maybe it wasn't clear.
Ge0rGI'm not sure if my mail to council@ went through, or if I need to fake somebody's email address.