XSF logo XMPP Council - 2017-10-18

  1. pep. has joined
  2. Tobias has joined
  3. Tobias has joined
  4. jere has left
  5. jere has joined
  6. daniel has left
  7. ralphm has left
  8. daniel has left
  9. SamWhited has left
  10. jere has left
  11. Syndace has left
  12. Syndace has joined
  13. daniel has left
  14. daniel has joined
  15. ralphm has left
  16. Tobias has left
  17. ralphm has left
  18. ralphm has joined
  19. ralphm has left
  20. ralphm has left
  21. Tobias has left
  22. jonasw has left
  23. Zash has left
  24. ralphm has left
  25. ralphm has joined
  26. Kev has left
  27. jere has joined
  28. ralphm has left
  29. daniel has left
  30. ralphm has left
  31. Syndace has left
  32. Syndace has joined
  33. daniel has left
  34. ralphm has left
  35. Tobias has left
  36. ralphm has left
  37. daniel has joined
  38. ralphm has left
  39. jere has left
  40. Kev has left
  41. jere has joined
  42. pep. has left
  43. jere has left
  44. jere has joined
  45. Kev has joined
  46. daniel has left
  47. daniel has joined
  48. ralphm has left
  49. daniel has left
  50. jere has left
  51. ralphm has left
  52. Ge0rG is it that day of the week again?
  53. SamWhited Indeed it is.
  54. Link Mauve Yep, and I’m not ill anymore!
  55. Tobias 1) Roll call
  56. Link Mauve o/
  57. Tobias daniel, SamWhited, Dave
  58. dwd has joined
  59. dwd waves
  60. dwd Sorry, on 4G with conversations and it was trying to join the MUC with an disconnected account.
  61. SamWhited Here
  62. daniel oh. yes i'm here
  63. Tobias yay...everybody here
  64. daniel forgot that it's wednesday again
  65. Tobias 2) Minute taker
  66. Tobias any volunteer?
  67. dwd I can't I'm afraid; on a tablet and it's not very easy to multitask.
  68. SamWhited daniel: it's Wednesday every week at this time
  69. Ge0rG shall I?
  70. Tobias Ge0rG, thanks
  71. jonasw has left
  72. jonasw has joined
  73. Tobias 3) Vote on accepting https://github.com/xsf/xeps/pull/528 " XEP-0071: make security considations much clearer #528 "
  74. Link Mauve +1, there are other things I want to add next but it already is a net improvement.
  75. SamWhited +1
  76. Tobias +1
  77. dwd +1
  78. daniel +1
  79. Tobias thanks
  80. Tobias 4) Vote on accepting ProtoXEP: Body Markup Hints https://xmpp.org/extensions/inbox/bmh.html
  81. Tobias I'll vote on list
  82. dwd I'd like to see how the discussion goes on this one.
  83. Tobias I'll interpret that as 'on list' :)
  84. Link Mauve I’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).
  85. dwd You can interpret it as not voting yet, indeed.
  86. daniel i'm not a huge fan of the XEP personally but technically it looks fine. so +1 from me
  87. SamWhited I'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)
  88. Tobias alright
  89. Link Mauve (My -1 might change, but not with the XEP as is.)
  90. Ge0rG Link Mauve: is "very much -1" a -1 vote?
  91. Link Mauve Yes. :)
  92. dwd I'd appreciate a debate on list about this, mind - I'd like to explore how we might change your mind.
  93. Tobias 5) Vote on accepting ProtoXEP: Atomically Compare-And-Publish PubSub Items https://xmpp.org/extensions/inbox/cap.html
  94. Tobias I'm on list on this too
  95. dwd I've not had a chance to review this properly yet, so I'll vote on list later.
  96. Link Mauve dwd, sure, but it’s already been mostly summarised in the long XHTML-IM thread, which I also read last night.
  97. daniel has left
  98. dwd Bad luck. :-)
  99. Link Mauve Tobias, on list too.
  100. daniel On list
  101. SamWhited +1
  102. SamWhited There 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.
  103. Tobias ok
  104. Tobias 6) Vote on accepting ProtoXEP: Jinge Encrypted Transports - OMEMO https://xmpp.org/extensions/inbox/jet-omemo.html
  105. Tobias also on list here, as I haven't read it yet
  106. Link Mauve On list too, for the same reason.
  107. dwd Jinge encrypted?
  108. daniel on list
  109. Link Mauve dwd, just a typo here. :)
  110. SamWhited on list
  111. dwd I think I'm +1 on this, given Paul's implemented it so the real errors are probably in spec not fundamental.
  112. Tobias ok
  113. Tobias The rest I think is pending external events or further discussion. Will ping respective people afterwards.
  114. Tobias 7) Date of next
  115. Tobias same time next week
  116. SamWhited What 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"
  117. SamWhited So I don't see any reason to hold off obsoleting it and indicating that we want to do formatting-nextgen
  118. jonasw I mentioned one
  119. jonasw but you might disregard it of course
  120. daniel i haven't had time to read through the thread
  121. Tobias SamWhited, we just started the discussion a week ago, i suggest waiting for next week to vote on obsoleting it
  122. Link Mauve SamWhited, jonasw’s email was very detailed about why we shouldn’t do that without a path forward.
  123. jonasw 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 replacement). (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 discussion*).
  124. Tobias like daniel, i haven't read all the mails in that thread yet
  125. dwd Yeah, 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.
  126. SamWhited Let's discuss next week then
  127. Link Mauve Ack.
  128. Tobias so time for next, as usual
  129. Tobias 8) AOB
  130. Link Mauve Wfm.
  131. dwd AOB - I noticed the email from Klaus; we should probably consider that *before* someone demonstrates the problem...
  132. dwd Perhaps simply [re]confirming votes on list in this room would be enough?
  133. Link Mauve While making sure we are using our usual JID?
  134. SamWhited Sounds 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"
  135. Tobias Reminder 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"
  136. Link Mauve SamWhited, that was the answer I was going to make after this meeting, that we should be aware of the emails “we” send.
  137. Tobias +1 on what SamWhited said
  138. Link Mauve Basically monitor the mailing list.
  139. Link Mauve Oh, and only us can post to council@, correct?
  140. dwd That may well be sufficient, too.
  141. jonasw SamWhited, given that nobody reads all emails on list, I find that a not-so-good solution.
  142. jonasw GPG would be nice
  143. Kev Link Mauve: Yes, and thankfully email can't be forged ;)
  144. dwd Yes, but that means anyone using your email address.
  145. Kev jonasw: Council do, though, that's kinda the point.
  146. jonasw Kev, okay, if you say so :)
  147. pep. has joined
  148. Link Mauve Kev, do you mean the ML software isn’t checking my server is actually who it pretends to be? :(
  149. dwd Good luck with finding a standard for that.
  150. Link Mauve jonasw, I make a point in reading everything, even if I don’t always answer.
  151. Kev dmarc will solve everything.
  152. jonasw Link Mauve, how would it? :)
  153. jonasw SPF would be an option, sure...
  154. Kev But yes, I think that's the worst bit of being on Council, the responsibility to process every single blasted mail.
  155. jonasw email is a mess.
  156. jonasw Kev, didn’t know that it was a requirement.
  157. Tobias another 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?
  158. Ge0rG Tobias: Hints was -1ed, so that PR is in limbo
  159. Tobias Limbo?
  160. Link Mauve Ge0rG, would it get unblocked by your suggestion of better semantic hints?
  161. Ge0rG Tobias: I'd like to hear if the council is +1 on the proposed wording change, to make the rules stricter
  162. Kev I'm still -1 on enforcing the rules, FWIW.
  163. Ge0rG Kev: what would make you change your mind?
  164. daniel has left
  165. Kev Ge0rG: Having the big picture clear and agreed first.
  166. jonasw I 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.
  167. Ge0rG Kev: so I should continue with my TLDR posts?
  168. Link Mauve I want to take part into that big whiteboard routing party, where do I sign?
  169. Tobias TLDR is always nice
  170. Kev Ge0rG: Absolutely. And I should read the one you sent the other day.
  171. Ge0rG Kev: that's not very motivating.
  172. SamWhited I 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.
  173. Kev I promise I'm going to, if that helps. But, busy week.
  174. SamWhited *big
  175. jonasw I’m all in for whiteboarding, if I can attend somehow :)
  176. Tobias ok..any further AOB topics?
  177. Tobias doesn't look like it
  178. Tobias bangs the gavel
  179. Tobias thanks everybody
  180. SamWhited *whew* busy meeting; thanks all!
  181. Tobias thanks Ge0rG for taking notes
  182. Link Mauve Thanks all. :)
  183. Tobias please send them to standards@ and council@
  184. Flow Link Mauve, "waiving any format support"?
  185. Tobias btw: people interesting in serving on council, please add at https://wiki.xmpp.org/web/Board_and_Council_Elections_2017
  186. jonasw is nobody gonna re-apply?
  187. Link Mauve Flow, 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.
  188. Tobias jonasw, probably people are too busy and haven't added them yet
  189. jonasw disco doesn’t work, I should’ve added that
  190. jonasw (to my email on that protoxep)
  191. Link Mauve <body-markup-hint language="text/html"/> is totally fine, as an example.
  192. jonasw oh the pain
  193. Flow Link Mauve, I don't think the situation is comperable to xep380
  194. Link Mauve shivers in horror, remembering Adium’s OTR <FONT>…
  195. jonasw that sounds so much like things libpurple would do.
  196. Link Mauve jonasw, Tobias, it isn’t the day before the deadline, nobody has even started working on their application. :p
  197. Flow So, 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/>
  198. jonasw I find that a super bad idea
  199. jonasw you shouldn’t be doing that in the first place
  200. Flow And all I want to achieve with BMH is to tell the receiving entity: Hey, there is CommonMark in the <body/>
  201. Link Mauve Flow, not making the effort of using a library to generate a common format that everyone understands is a very bad practice, imo.
  202. Flow jonasw, but I will do that, and others will also
  203. jonasw either you care about interop (and use a separat element + plaintext variant in <body/>), or you don’t
  204. jonasw tacking a "greenwashing" "oh and if you happen to support my unspecified format, this is it" tag doesn’t make things a whole lot better
  205. Link Mauve If 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.
  206. Flow I think <body/> is the highest level of interop
  207. jonasw putting markup in <body/> isn’t
  208. Flow So I do care very much
  209. Link Mauve Yes, I agree on that.
  210. Link Mauve jonasw, exactly.
  211. Flow Link Mauve, I don't assume that
  212. Flow but I give him a hint that it's CommonMark
  213. jonasw putting marked-up things in body could easily break accessibility tools
  214. Flow jonasw, …
  215. Link Mauve Flow, if my client doesn’t support CommonMark but reST, will you convert that for me?
  216. jonasw Flow, …?
  217. jonasw FWIW, I’ve heard "there are no accessible clients for jabber" more than once as a reason not to use it.
  218. Flow Link Mauve, If the data I have is already formated in CommonMark, possibly not
  219. jonasw while many of the hip messengers in fact are quite accessible.
  220. Link Mauve If 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?
  221. Flow I feel like the XEP would had more acceptance if there was no disco part
  222. jonasw the disco part is irrelevant, because it doesn’t work
  223. Flow Link Mauve, that's another aspect
  224. jonasw it 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
  225. Link Mauve Flow, all that just because you couldn’t find a library to generate XHTML-IM from your CommonMark?
  226. jonasw (also, shouldn’t we move this discussion to xsf@?)
  227. Kev Ge0rG: Because I'd hate to demotivate you.
  228. Link Mauve (I’m some 2000+ lines up in that buffer, I have a lot of backlog to read before that discussion then. :x)
  229. Link Mauve (Damn being ill!)
  230. jonasw :(
  231. Ge0rG Sorry, I just got a bunch of work calls. Now working up the AOBs.
  232. Ge0rG dwd: what's the context of "dwd> AOB - I noticed the email from Klaus; we should probably consider that *before* someone demonstrates the problem..."?
  233. Kev Ge0rG: Voting on list without sender verification.
  234. Ge0rG can I write that into the Minutes?
  235. Kev It was an AOB, yes.
  236. SamWhited I 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.
  237. ralphm has left
  238. Ge0rG I'm not sure if my mail to council@ went through, or if I need to fake somebody's email address.
  239. Flow has left
  240. Flow has joined
  241. daniel has left
  242. ralphm has left
  243. jere has joined
  244. ralphm has left
  245. jere has left
  246. jere has joined
  247. daniel has left
  248. ralphm has left
  249. ralphm has left
  250. dwd has left
  251. Tobias has joined
  252. dwd has left
  253. ralphm has left
  254. daniel has left
  255. SouL has left
  256. jere has left
  257. dwd has left
  258. dwd has left
  259. dwd has left
  260. ralphm has left
  261. dwd has left
  262. Holger has left
  263. Holger has left
  264. Zash has left
  265. dwd has left
  266. dwd has left
  267. dwd has left
  268. dwd has left
  269. dwd has left
  270. dwd has left
  271. dwd has left
  272. dwd has left
  273. SamWhited has left
  274. SamWhited has left
  275. SamWhited has joined