XMPP Council - 2021-08-11


  1. Kev has left
  2. Kev has joined
  3. Kev has left
  4. Kev has joined
  5. Sam has left
  6. Sam has joined
  7. Kev has left
  8. Kev has joined
  9. Kev has left
  10. takaeshi has joined
  11. takaeshi has left
  12. takaeshi has joined
  13. takaeshi has left
  14. Ge0rG has left
  15. Ge0rG has joined
  16. Tobias has joined
  17. ChronosX88 has left
  18. ChronosX88 has joined
  19. takaeshi has joined
  20. takaeshi has left
  21. takaeshi has joined
  22. takaeshi has left
  23. vaulor has left
  24. takaeshi has joined
  25. takaeshi has left
  26. takaeshi has joined
  27. takaeshi has left
  28. takaeshi has joined
  29. debacle has joined
  30. vaulor has joined
  31. takaeshi has left
  32. takaeshi has joined
  33. debacle has left
  34. debacle has joined
  35. takaeshi has left
  36. takaeshi has joined
  37. Kev has joined
  38. takaeshi has left
  39. takaeshi has joined
  40. takaeshi has left
  41. takaeshi has joined
  42. takaeshi has left
  43. takaeshi has joined
  44. takaeshi has left
  45. takaeshi has joined
  46. takaeshi has left
  47. takaeshi has joined
  48. takaeshi has left
  49. takaeshi has joined
  50. ChronosX88 has left
  51. ChronosX88 has joined
  52. ChronosX88 has left
  53. Wojtek has joined
  54. takaeshi has left
  55. takaeshi has joined
  56. takaeshi has left
  57. takaeshi has joined
  58. takaeshi has left
  59. David has left
  60. takaeshi has joined
  61. David has joined
  62. takaeshi has left
  63. takaeshi has joined
  64. pprrks has joined
  65. Wojtek has left
  66. takaeshi has left
  67. takaeshi has joined
  68. Dave Cridland has joined
  69. Kev has left
  70. Kev has joined
  71. Kev has left
  72. Kev has joined
  73. Kev has left
  74. Kev has joined
  75. daniel Hi
  76. Ge0rG I've heard it's that special date and time again, but I'm still on the run
  77. Zash My gosh, is this the time?
  78. daniel Do we have a jonas’?
  79. takaeshi has left
  80. Dave Cridland Hiya.
  81. Zash Dun dun duuun
  82. jonas’ 1) Roll Call
  83. jonas’ sorry
  84. jonas’ thanks Zash for poking me
  85. Zash Here. Full house?
  86. jonas’ I was sunken deeply in the horrifying lecture which is https://counterexamples.org/
  87. jonas’ either way, welcome everyone
  88. jonas’ 2) Agenda Bashing
  89. jonas’ this time, it was not a late agenda, which is good and surprising given the chaotic day I had yesterday. I don't even remember much of writing it :)
  90. jonas’ please complain about anything which might be missing inline and asap
  91. jonas’ 3) Editor's Update
  92. jonas’ Pubsub Caching Hints have been accepted as New as per council vote
  93. jonas’ also, the moved 2.0 protoxep has been merged into '283 and authorship has been transferred to MattJ as discussed
  94. jonas’ 4) Items for Voting
  95. jonas’ None, as far as I know.
  96. jonas’ 5) Pending votes
  97. jonas’ - Georg on ProtoXEP https://xmpp.org/extensions/inbox/disco-feature-attachment.html
  98. jonas’ I note that there has been some discussion on list about this
  99. jonas’ I think Stephen makes some valid points
  100. jonas’ but there was also more discussion in xsf@ and my personal take away is that the proposal isn't really sensible after all
  101. Zash "the proposal" = the protoXEP or what was posted to the list?
  102. jonas’ both!
  103. daniel fwiw i never "liked" the XEP. but i think it's speced out well enough to deserve being an experimental xep
  104. Dave Cridland I thought it seemed quite sensible for RSM (and needed), and I was willing to see how the Generic version played out.
  105. daniel just be careful with implementing it and more careful with referencing it from other xeps
  106. jonas’ -1, my rationale being the following, but I can be persuaded: - Any disco#info feature needs to be backed by some kind of implementation text - Even though for some combination of features the implementation may be obvious, it should still be written down somewhere, because obvious doesn't really work - If there is text backing the implementation of a combination of two features, that is the obvious place to declare a disco#info feature string - If there is a place where a disco#info string is written down which needs to be read by implementors anyway, there is no benefit from having a way to construct such a string; an opaque string match is required in the implementation anyway.
  107. jonas’ and to bring this to the point which IMO makes this -1-worthy: it misleads implementations and specification authors to think that they can just slap together two feature strings and it will be immediately clear what is supposed to happen there.
  108. daniel i (mostly?) agree with your points. to me this doesn’t necessarily warent a -1
  109. Ge0rG I'm with jonas’, plus introducing @ as a special character in an otherwise opaque identifier is kinda evil
  110. daniel but i respect your choice to veto
  111. jonas’ daniel, I may be over the line here, however, I think this may be actievly harmful
  112. jonas’ at the same time, I acknowledge that we need to solve the issue that an entity declaring RSM and an entity declaring e.g. MAM or PubSub or '0030 is not clear about how and where RSM is supported
  113. jonas’ I think the discussion in xsf@ about this has been guiding in the sense that it became clear in which documents those specific cases need to be addressed (if at all -- I think MAM clearly references RSM already and hard-depends on it, so MAM feature implies RSM anyway)
  114. Ge0rG Yeah, it creates a precedent for a really bad practice. In the end, somebody will add a matrix of all possible combinations of main feature × supporting feature
  115. Dave Cridland Well, certainly this could be solved more immediately by a set of RSM+Pubsub (etc) features.
  116. Zash So the root problem is signaling optional dependencies?
  117. daniel fair. (it once again boils down to what experimental means)
  118. jonas’ Zash, I think so
  119. jonas’ Zash, because for mandatory dependencies it doesn't matter.
  120. jonas’ in the end, RSM should never have had a feature string :)
  121. Ge0rG Or by requiring MAM to support RSM without a distinct disco feature
  122. Zash Yeah, you don't need to advertise something that is implied by e.g. the MAM feature.
  123. jonas’ I'm going with -0, because I may be wrong about this and Experimental may still be a place for it. I'll post my concerns on the list so that others can weigh in.
  124. jonas’ Ge0rG, your vote please.
  125. Zash Maybe this should be turned into an Informational XEP, as I think was mentioned in xsf@
  126. jonas’ Zash, even that is not useful in my opinion
  127. Ge0rG Zash: I don't like that idea
  128. Dave Cridland Zash, I don't think that really solves anything.
  129. Dave Cridland I am finding myself swayed by your arguments,here, jonas’ + Ge0rG.
  130. Ge0rG jonas’: -0 from me as well, because I fully agree that we need explicit wording for optional dependencies, where we easily can define their own feature during
  131. Ge0rG jonas’: -0 from me as well, because I fully agree that we need explicit wording for optional dependencies, where we easily can define their own feature string
  132. Zash General guidelines for advertising support for optional use of other XEPs, whether by "X@Y" or "Y#x"
  133. Ge0rG Zash: maybe that's something where an editor can easily change the strings during submission?
  134. jonas’ I think introducing some kind of "syntax" is useful for the humans in the XMPP stack.
  135. jonas’ even if no code can make automated decisions based on the syntax
  136. Dave Cridland I think this is a problem that needs addressing for RSM, for sure. But the generic nature of this approach is a bit of a risk.
  137. jonas’ okay
  138. jonas’ proposal
  139. Ge0rG Somebody would have to go through all of our existing XEPs to check for prior art
  140. jonas’ it seems that this discussion has become a bit complicated. shall we prolong our voting period by another week?
  141. jonas’ I am currently typing a long email in response to the thread to involve the author in this
  142. Dave Cridland SO I'm wondering about switching to veto, with a resolution of removing the generic nature of this - that is, make it explicitly about RSM and making each feature explicitly defined, and then I think that addresses all our concerns "for now"?
  143. Ge0rG Also there is the mess called 0045
  144. jonas’ Dave Cridland, that's kind of what I'm going to propose on-list anyway, so go for it IMO
  145. jonas’ Ge0rG, what's got '45 to do with this?
  146. Zash Combinations of things?
  147. takaeshi has joined
  148. Dave Cridland I'll change to veto then. I think that leaves open a generic solution if one seems needed.
  149. jonas’ ACK thx
  150. Ge0rG jonas’: inconsistently named optional features
  151. jonas’ Ge0rG, doesn't matter, opaque strings ;)
  152. jonas’ but yeah
  153. jonas’ okay, last call for votes on this protoxep because we all did a lot of switcheroo here
  154. jonas’ daniel, Zash, any changes?
  155. Zash Good arguments, so -0 I think?
  156. Zash Or hold until the list discussion comes to a conclusion
  157. daniel yeah. it doesn’t matter; but i'm fine with rejecting it after hearing the arguments
  158. daniel it=my vote
  159. jonas’ okay
  160. jonas’ thanks all
  161. jonas’ I'm going to write an extensive email into the thread to explain all this to the author and also to singpolyma
  162. jonas’ 6) Date of Next
  163. jonas’ +1w wfm
  164. Zash +1w wfm
  165. Dave Cridland +1w wfm
  166. daniel +1w wfm
  167. Ge0rG +1W WFM
  168. jonas’ 7) AOB
  169. jonas’ anything?
  170. Dave Cridland Not from me.
  171. jonas’ nobody else is moving so
  172. jonas’ 8) Ite Meeting Est
  173. jonas’ thanks everyone
  174. jonas’ I'm going to write the email in the thread and compile minutes :)
  175. daniel thanks jonas’
  176. Dave Cridland Thanks jonas’ !
  177. Kev has left
  178. Kev has joined
  179. jonas’ mail sent in that thread, minutes sent, thanks everyone.
  180. takaeshi has left
  181. jonas’ dives back into "Counterexamples"
  182. takaeshi has joined
  183. Zash dives into a bag of potatoes
  184. Kev has left
  185. Kev has joined
  186. takaeshi has left
  187. ChronosX88 has joined
  188. mdosch Bag? You bought them? I thought your growing them in the woods.
  189. jonas’ mdosch, and how do you collect them if not in a bag?
  190. mdosch Hmm, treu.
  191. mdosch Hmm, true.
  192. takaeshi has joined
  193. Kev has left
  194. Kev has joined
  195. pprrks has left
  196. takaeshi has left
  197. takaeshi has joined
  198. takaeshi has left
  199. takaeshi has joined
  200. debacle has left
  201. Dave Cridland has left
  202. Kev FWIW, I think veto was the right call, and Jonas has roughly repeated the points I tried to make in xsf@ the other day, more elloquently
  203. Kev (Jonas than me)
  204. takaeshi has left
  205. takaeshi has joined
  206. takaeshi has left
  207. debacle has joined
  208. ChronosX88 has left
  209. ChronosX88 has joined
  210. takaeshi has joined
  211. ChronosX88 has left
  212. ChronosX88 has joined
  213. takaeshi has left
  214. takaeshi has joined
  215. ChronosX88 has left
  216. takaeshi has left
  217. takaeshi has joined
  218. ChronosX88 has joined
  219. takaeshi has left
  220. takaeshi has joined
  221. Dave Cridland has joined
  222. takaeshi has left
  223. takaeshi has joined
  224. takaeshi has left
  225. Dave Cridland has left
  226. Kev has left
  227. Kev has joined
  228. Kev has left
  229. Kev has joined
  230. Tobias has left
  231. debacle has left
  232. eta has left
  233. eta has joined
  234. takaeshi has joined
  235. takaeshi has left
  236. takaeshi has joined
  237. takaeshi has left
  238. takaeshi has joined
  239. takaeshi has left
  240. takaeshi has joined
  241. takaeshi has left