XMPP Council - 2021-04-28


  1. moparisthebest has left
  2. moparisthebest has joined
  3. stpeter has left
  4. stpeter has joined
  5. stpeter has left
  6. Tobias has joined
  7. Syndace has left
  8. Syndace has joined
  9. paul has joined
  10. Tobias has left
  11. Syndace has left
  12. Syndace has joined
  13. Tobias has joined
  14. mdosch has left
  15. mdosch has joined
  16. debacle has joined
  17. marc0s has left
  18. marc0s has joined
  19. Syndace has left
  20. Syndace has joined
  21. Wojtek has joined
  22. debacle has left
  23. Syndace has left
  24. Syndace has joined
  25. Wojtek has left
  26. Wojtek has joined
  27. Syndace has left
  28. Syndace has joined
  29. Zash jonas’, agenda?
  30. jonas’ chaos yesterday, dropped off my todo somehow
  31. jonas’ I initially thought I had a time window for that and then the pandemic cancelled that time window and my head did not schedule a replacement and here we are
  32. jonas’ but I think we don’t have anything anyway
  33. Ge0rG something something CVE, something something must update 0280
  34. jonas’ sent a pro forma one
  35. jonas’ yep, we’ll have lots of time for AOB
  36. Syndace has left
  37. Syndace has joined
  38. Kev_ has joined
  39. Kev__ has joined
  40. Kev__ has left
  41. Kev_ has left
  42. Ge0rG Yay!
  43. stpeter has joined
  44. Kev_ has joined
  45. Kev__ has joined
  46. Kev_ has left
  47. Kev__ has left
  48. jonas’ 1) Roll Call
  49. Zash Ehol
  50. daniel hi
  51. Zash Ehlo
  52. jonas’ anticipating a Ge0rG and a possible dwd
  53. dwd Hello.
  54. Ge0rG Oh, it's that late already?
  55. jonas’ it is :)
  56. jonas’ 2) Agenda Bashing
  57. Ge0rG Good morning, everyone!
  58. jonas’ bad agenda! late agenda!
  59. jonas’ also, empty agenda
  60. jonas’ 3) Editor’s Update
  61. jonas’ Nothing, but editor didn’t do anything. Bad editor!
  62. jonas’ 4) Items for Voting
  63. jonas’ none
  64. Zash Yay
  65. jonas’ 5) Pending Votes
  66. jonas’ all clear
  67. Zash Yay!
  68. jonas’ 6) Date of Next
  69. Ge0rG +3W WFM
  70. jonas’ +1w wfm
  71. jonas’ Ge0rG, have a nice vacation!
  72. Zash +1w wfm
  73. daniel +1w wfm
  74. Ge0rG jonas’: I'll try my best
  75. dwd The same time next week works for me.
  76. jonas’ excellent
  77. jonas’ 7) AOB
  78. jonas’ Ge0rG had some I think
  79. Ge0rG Oh, I'm kinda unprepared.
  80. Ge0rG I think you mentioned something about bringing uo the CVE thing on standards.
  81. Ge0rG I think you mentioned something about bringing up the CVE thing on standards. Which I didn't do yet.
  82. Kev_ has joined
  83. Kev__ has joined
  84. Ge0rG And I have a hard time remembering last week's conclusion of what to do with <private/> and no-copy.
  85. dwd My AOB is that I'm getting a COVID vaccine shortly, which seems a bit pointless as I don't even have a 5G phone.
  86. jonas’ dwd, congrats!
  87. jonas’ scrolls up to answer Ge0rGs implicit question
  88. Zash Something about not removing <private> IIRC
  89. jonas’ Ge0rG, the summary was, I think, that if you want to remove that strange <private/> behaviour, add a feature to indicate that the server in fact executes the new behaviour
  90. jonas’ otherwise it will do nothing good except chaos
  91. Ge0rG Why didn't we add a feature the last time we changed <private/> stripping rules?
  92. jonas’ oversight?
  93. jonas’ past wrongs don’t give permission for new wrongs
  94. Ge0rG I had a slight hope that the past wrong would be cancelled out by the upcoming wrong
  95. Kev I’m not even convinced that the last change wasn’t a mistake.
  96. jonas’ no, because there are a few years of practical deployment inbetween
  97. Kev But I don’t think that means fixing it can skip the needful.
  98. Ge0rG jonas’: given the amount of server developer feedback, I'm not sure this is true at all ;)
  99. jonas’ Ge0rG, yes, the lack of feedback does not allow us to come to any conclusion.
  100. jonas’ hence, we have to play it safe
  101. Kev “Lack of feedback” doesn’t actually mean lack of feedback, does it?
  102. jonas’ even if the only diff on the server side would be adding a thing to disco#info
  103. Kev There’s been lots of feedback, IIRC, in response to some of the previous 2039871032730987 last calls.
  104. jonas’ Kev, I think Ge0rG meant to reference lack of feedback on that specific issue
  105. Ge0rG Okay, so I'll move forward by removing the stripping and adding a no-stripping feature.
  106. dwd Kev, Maybe we should keeping having more and more last calls until eventually we get no feedback at all and we can reject it on that basis instead.
  107. Ge0rG Now what about no-copy hints?
  108. Ge0rG dwd: That's an excellent idea
  109. Zash LC of Zeno?
  110. Kev_ has left
  111. Kev__ has left
  112. jonas’ ok
  113. jonas’ silence
  114. jonas’ Ge0rG, I have no opinion on no-copy hints
  115. Ge0rG Well, my (serious) question still stands.
  116. jonas’ nor do I have a clear picture about the implications
  117. jonas’ Ge0rG, could you summarize your thoughts on no-copy?
  118. jonas’ i.e. what is the current situation, what is bad about it and what would you like to change?
  119. Ge0rG jonas’: no-copy was added as an AND requirement for clients after <private/> was there
  120. Ge0rG the requirements for servers are vague, at best
  121. Ge0rG IMO, removing no-copy will not do any harm to specification-abiding implementations
  122. Ge0rG The only corner case I see is when a receiving client would rely on no-copy being there while <private/> being stripped by a stripping server.
  123. Ge0rG Sorry, somebody decided that *now* would be a good time to send thousands of vaccination notifications.
  124. daniel (I just checked the only time I use no-copy in Conversations is when I send a direct-invite to my own connected resources to inform them that I've just joined a new muc. Which has arguably been made obsolete now that we have bookmarks in PEP)
  125. jonas’ daniel, lovely hack though :)
  126. jonas’ love the attention to detail in there
  127. Ge0rG daniel: why not sending one invite to your bare JID?
  128. daniel to avoid receiving it on my own client i guess
  129. jonas’ Ge0rG, OK, I don’t have strong opinions on that
  130. jonas’ as I assume that many implementations would handle <private/> even if <no-copy/> was absent if the XEP is worded vaguely
  131. Ge0rG jonas’: that's my conclusion as well
  132. Ge0rG Okay, thanks everybody for the fruitful discussion. I think I'm out of AOBs for now.
  133. jonas’ I sense sarcasm
  134. jonas’ anyway
  135. jonas’ dwd, do you want to elaborate on your AOB? :)
  136. Ge0rG I'd never dare to
  137. daniel what are we achieving by stripping or not stripping that element?
  138. Ge0rG daniel: we get rid of legacy
  139. daniel by stripping it?
  140. Ge0rG yes
  141. daniel so you want to reintroduce legacy by telling servers to not strip it?
  142. Zash I seem to have lost track of what exactly the question was
  143. daniel yes. me too
  144. daniel that's why i'm asking
  145. Ge0rG daniel: I don't follow
  146. Ge0rG daniel: did you ask about no-copy or about private?
  147. Ge0rG "that element" appears ambiguous in retrospect
  148. Zash no-copy → strip from the XEP private → don't strip from stanzas ?
  149. Ge0rG what Zash said!
  150. dwd It seems to me that we've spent nearly half an hour doing protocol design in a Council meeting. Can we not write a proposal to the list, see if there's concensus to do anything (or nothing), and go from there?
  151. Ge0rG dwd: sure
  152. Ge0rG puts it on his agenda
  153. jonas’ dwd is a smart person
  154. jonas’ let’s do what dwd s ays
  155. Zash +1
  156. jonas’ any other AOB?
  157. Zash none here
  158. dwd None from me.
  159. daniel none here either
  160. jonas’ then I wish you all a pleasant rest of the day
  161. jonas’ 8) Ite Meeting Est
  162. jonas’ thanks all
  163. Zash Thanks jonas’
  164. Zash Thanks tedd
  165. Zash and thanks all
  166. Ge0rG Thanks!
  167. daniel Message Carbons is weird legacy anyway. I don’t thing we gain anything from messing with no-copy and private
  168. daniel yes it was a mistake to introduce no-copy
  169. daniel but those extra bytes don’t matter
  170. Ge0rG No need to cement that mistake into eternity
  171. daniel considering the overhead that carbons has anyway
  172. daniel i really hope that Carbons don’t hang around for an eternity
  173. dwd I'd be curious as to whether it matters if it *is* baked into eternity.
  174. dwd I mean, if it's there already in implementations, does it matter?
  175. daniel plus looking at the history of the XEP it seems that stripping <private/> was a requirement before no-copy was even introduced
  176. daniel so the stripping of private is not to remove redundant information after the introducting of no-copy
  177. daniel it was there before
  178. daniel i don’t know why
  179. daniel so even if you were to remove no-copy you don’t need to mess with the stripping or not stripping of private
  180. Kev I think it was a mistake.
  181. daniel everything?
  182. Kev Looking at the changelog, the changelog seems to suggest it was trying to do the opposite of what it does.
  183. Kev No, adding the stripping of private.
  184. Zash Everything! Climbing down from the trees especially
  185. debacle has joined
  186. daniel considering that there are very few use cases for private/no-copy I suggest that we accept the fact that Carbons is not pretty but de facto draft and just leave everything as is and declare it as such
  187. Zash mmm
  188. jonas’ weren’t we there already last week?
  189. Zash and try for a reasonable upgrade path to IM-NG?
  190. jonas’ however, the stripping of private might be considered actively harmful
  191. Kev I consider it is, yes.
  192. jonas’ so fixing that before moving to draft may be worthwhile
  193. daniel so remove no-copy don’t strip private?
  194. Ge0rG remove stripping of private, remove no-copy from XEP
  195. daniel yes
  196. Ge0rG 👍
  197. daniel Can anyone think of a scenario of a receiving client that relies on the stripping?
  198. Kev No.
  199. daniel Because that's the breaking change here, right?
  200. Zash Anyone remember why it's even stripped?
  201. Kev Depending on one’s definition of breaking, yes.
  202. Zash ISTR some privacy issue or something
  203. Kev Zash: As I say above, I think it was a mistake. The changelog says that it was removed, but instead it was added.
  204. Ge0rG I think there was a version of Carbons that required the *sending* server to strip, but then somebody realized that the receiving server needs that info as well
  205. Wojtek has left
  206. Wojtek has joined
  207. Zash Makes sense, I think Prosody still follows that 😕
  208. Ge0rG Zash: prosody will strip on the sending server?
  209. Zash y
  210. daniel Fun
  211. Zash Unless I'm mistaken
  212. debacle has left
  213. Wojtek has left
  214. daniel OK. I've changed my mind. You have my blessing to remove the no-copy hint from the xep and remove the requirement to strip private
  215. daniel (not that you need that since you are the author and the xep is experimental)
  216. dwd Forever...
  217. Ge0rG if that's true, the fact that nobody noticed it yet speaks tomes.
  218. Zash Hm, nm, seems to strip it on the receiving end only
  219. Ge0rG so I've replaced the SDK shipped with AS by OpenJDK 12.
  220. Zash Wrong room?
  221. Ge0rG Ooops, that was the wrong place.
  222. Wojtek has joined
  223. debacle has joined
  224. paul has left
  225. paul has joined
  226. paul has left
  227. paul has joined
  228. Syndace has left
  229. Syndace has joined
  230. Ge0rG is it me or are we missing Council minutes for April? I tried to find the "mention CVE PR on-list" statement in either my local logs or the Minutes and failed :(
  231. jonas’ hmm
  232. jonas’ possible
  233. jonas’ I hope Tedd is alright
  234. Ge0rG Yeah, that was also my first thought.
  235. Ge0rG And my second thought was, that this kind of thought is very frightening, if the only regular interaction with somebody is them writing a summary email to a list.
  236. Ge0rG ah, found it. 20210421T15:42:30Z
  237. Syndace has left
  238. Syndace has joined
  239. Ge0rG jonas’: https://mail.jabber.org/pipermail/standards/2021-April/038301.html
  240. Wojtek has left
  241. Syndace has left
  242. Syndace has joined
  243. Syndace has left
  244. Syndace has joined
  245. Syndace has left
  246. Syndace has joined
  247. Syndace has left
  248. Syndace has joined
  249. Tobias has left
  250. theTedd has joined
  251. theTedd jonas’, Tedd is alright ;)
  252. theTedd just been otherwise distracted
  253. theTedd minutes will magically appear, probably
  254. debacle has left
  255. Syndace has left
  256. Syndace has joined
  257. theTedd has left
  258. Syndace has left
  259. Syndace has joined
  260. Syndace has left
  261. Syndace has joined
  262. Zash has left
  263. Zash has joined
  264. Syndace has left
  265. Syndace has joined