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