XSF logo XMPP Council - 2019-05-08


  1. peter has left
  2. vanitasvitae has left
  3. peter has joined
  4. vanitasvitae has joined
  5. peter has left
  6. susmit88 has joined
  7. susmit88 has left
  8. susmit88 has joined
  9. peter has joined
  10. susmit88 has left
  11. susmit88 has joined
  12. susmit88 has left
  13. susmit88 has joined
  14. susmit88 has left
  15. susmit88 has joined
  16. susmit88 has left
  17. susmit88 has joined
  18. susmit88 has left
  19. susmit88 has joined
  20. susmit88 has left
  21. susmit88 has joined
  22. peter has left
  23. susmit88 has left
  24. Zash has left
  25. Zash has joined
  26. Tobias has left
  27. Tobias has joined
  28. lnj has joined
  29. debacle has joined
  30. lnj has left
  31. lnj has joined
  32. peter has joined
  33. peter has left
  34. jonas’ Kev, IIRC, you wanted amendments to https://github.com/xsf/xeps/pull/784, can you please confirm that the changes Ge0rG made are okay with you?
  35. jonas’ Kev, and the same for https://github.com/xsf/xeps/pull/778
  36. jonas’ <nevermind>
  37. debacle has left
  38. dwd Afternoon all.
  39. jonas’ afternoon, dwd
  40. Ge0rG is semi present
  41. dwd So:
  42. dwd 1) Roll Call.
  43. jonas’ is here
  44. Kev Here
  45. jonas’ Link Mauve ?
  46. Link Mauve Hi, I’m here.
  47. dwd I see Georg's partial presence.
  48. dwd Excellent.
  49. dwd 2) Agenda Bashing
  50. jonas’ board wants us to talk about https://github.com/xsf/xeps/pull/780
  51. Kev Was there an agenda?
  52. dwd There was not. So, Kev, you remember that nice little Yaris I used to have before it got hit by an HGV yesterday? Well, something happened to it, see if you can guess why I got distracted. :-/
  53. Kev You driving? Ok?
  54. dwd My son driving - actually not so much driving, sicne the handbrake was on. No injuries, walking pace collision, but the car has received substantial unexpected remodelling.
  55. jonas’ oh dear, thank $deity
  56. Kev Quite.
  57. Link Mauve Ow.
  58. dwd But anyway, that's my exciting news. Given the cheapness of my cars, it's probably an insurance write-off.
  59. dwd So - #780 - anything else?
  60. jonas’ not that I knew
  61. Guus (that's the same son that is a pilot?)
  62. Ge0rG That AOB discussion from two weeks ago? I tried to remind the List, but it failed similarly to what Kev attempted
  63. dwd Guus, Yes. Better a minor car crash than a minor aircraft crash. :-)
  64. Zash has left
  65. jonas’ Ge0rG, what was the AOB again?
  66. dwd 3) Items Not For A Vote:
  67. dwd a) https://github.com/xsf/xeps/pull/780 (Editorial changes and XEP state)
  68. jonas’ I am +1 on that one for obvious reasons
  69. Zash has joined
  70. Ge0rG Why are you +1 if it's not for a vote?
  71. jonas’ I’m not sure if it’s for a vote or not, and this expresses my intent unambigiuously either way :)
  72. Kev My comment still stands that we have a definition based on versioning here already, and making that clearer would be good. Instead of the suggested wording.
  73. dwd Seve's point is interesting. Are you intending to mean that if a XEP has a substantial edit in (say) April, and a series of edits considered Editorial subsequently, it would still be moved to Deferred in October?
  74. jonas’ Kev, I’m still not sure we do, technically
  75. jonas’ dwd, yes
  76. Kev jonas’: XEP-0001 is only concerned with substantive edits (x.y), not the x.y.z versions we use for editorial stuff.
  77. Kev I'd rather we codified the use of x.y.z in XEP-0001 for Editorial changes.
  78. jonas’ that’s what I meant by ". So to be able to refer to that, we’d have to go ahead and write that down clearly. Which I’m not opposed to, in general, but time and stuff."
  79. Kev dwd: Believe it or not, based on the versioning requirements, that's what XEP-0001 already says.
  80. jonas’ that’s what I meant by "So to be able to refer to that, we’d have to go ahead and write that down clearly. Which I’m not opposed to, in general, but time and stuff."
  81. jonas’ if you folks think that needs more explanation and should be made clearer, I can put it on my todo to write that down
  82. dwd Kev, I believe you. But Seve's point is that the way that reads is that you can make a substantial edit to a document which causes it to be deferred.
  83. jonas’ an edit can never cause a document to be deferred
  84. jonas’ time does
  85. Link Mauve Yeah, removing the “or to” part would seem sensible.
  86. dwd jonas’, I think I lean toward defining versions properly and unequivocally, and then I think this particular change/clarification falls out of that automatically.
  87. jonas’ okay
  88. jonas’ so I’ll go ahead and do that
  89. dwd Link Mauve, Except an editorial change is intended to leave the move *to* Deferred unaffected, so ...
  90. dwd jonas’, Sorry for making more work for you.
  91. jonas’ it’s alright
  92. jonas’ I have been thinking about that one anyways
  93. Ge0rG That phrasing is not perfect, I agree with Seve
  94. jonas’ and yeah, that phrase is a weak spot in the diff
  95. jonas’ will fix both
  96. Link Mauve dwd, “[…] for the purpose of considering moving a XEP back from Deferred state, or keep it there.” maybe?
  97. dwd Link Mauve, As I say, once you define versioning clearly, I don't think it matters anymore.
  98. jonas’ I think it’s more effective when I draft up an alternative wording and we discuss it
  99. dwd So:
  100. Link Mauve jonas’, agreed.
  101. dwd b) That AOB That Georg Raised A Few Weeks Back.
  102. jonas’ Ge0rG, what was it even about?
  103. Ge0rG > Purely editorial changes (e.g. version updates from 0.1.1 to 0.1.2) count as <em>activity</em> (or <em>updates</em>) do not effect the Deferred state or deferral time of an XEP.
  104. Ge0rG it was about fixing 0184 properly
  105. jonas’ ah that
  106. jonas’ wasn’t that last week?
  107. jonas’ apparently not, and also it doesn’t matter
  108. Ge0rG the other AOB was asking Link Mauve to explain how to do MUC-0313 without exposing a DoS vector
  109. dwd Ge0rG, Which first?
  110. Ge0rG dwd: in that order please
  111. dwd Ge0rG, OK. 5 minutes on each then.
  112. dwd b) Fixing XEP-0184 properly.
  113. Link Mauve Ge0rG, I have never implemented 0313 in a server, I’m sure there are many better people than me for that.
  114. Ge0rG https://mail.jabber.org/pipermail/standards/2019-April/036083.html
  115. Ge0rG (Link Mauve: sorry, I meant 0308)
  116. jonas’ ah, about that
  117. Ge0rG That message-type info box in 0184 is a fig-leaf, and Kev asked to do it right in one of the last Council Meetings. Do we want to fix it properly?
  118. jonas’ I’m all in for fixing things properly
  119. jonas’ but we need to do it without a namespace bump, because there are other things we should include when we bump 184
  120. dwd I'm in favour of fixing things properly as a general rule. What do real implementations actually do?
  121. Ge0rG how far can I go with "fixing" it without you requiring a version bump?
  122. Ge0rG dwd: it varies wildly
  123. Ge0rG some reflect message type, others send normal. Some send to full JID, others to bare JID
  124. dwd Ge0rG, You bump a namespace when to implementations using the same namespace would fail to interoperate (or, indeed, already do).
  125. jonas’ Ge0rG, I’d say we specify that clients SHOULD send the same type, but MUST accept different types, too.
  126. Ge0rG dwd: the XEP does not mention message types.
  127. jonas’ mention why it makes sense to have that (archive stuff)
  128. Ge0rG (except when treating MUCs)
  129. dwd Ge0rG, I have noticed that some (COnverse, perhaps?) only handle receipts in type='chat'. I'd thought receipts were meant to be in type='normal' myself.
  130. Ge0rG dwd: "were meant to" is your reading of the XEP or some background knowledge?
  131. Ge0rG type=normal + no body leads to them being ephemeral for MAM and Carbons.
  132. Link Mauve Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.
  133. Ge0rG Link Mauve: please wait for AOB c.
  134. Link Mauve Ack.
  135. dwd Ge0rG, I read the XEP and implemented my end, and it failed. But Example 4, for example, shows a normal message.
  136. Ge0rG dwd: no, it shows a message with default message type.
  137. jonas’ which is type normal
  138. Ge0rG I claim that this is an oversight of the XEP author and not a deliberate design decision.
  139. Ge0rG And it's not normative in any case.
  140. dwd Ge0rG, So what does "fixed" look like? Same type? I personally think that 1:1 receipts ought to be in type='normal', and not type='chat' (since they're not chat messages). But I'm not wed to that idea.
  141. Ge0rG dwd: the pseudo-quote block in https://mail.jabber.org/pipermail/standards/2019-April/036090.html
  142. jonas’ The receiving client should consider the following when generating a Receipt, depending on the message type of the message that contained the Receipt Request: - "chat", "normal": the Receipt message SHOULD have the same @type as the Request message. - "groupchat": it is NOT RECOMMENDED to request Receipts in a MUC. A client choosing to respond despite of this SHOULD send the Receipt with type="groupchat" to the bare JID of the room and not to the full JID of the sender. It MAY be useful to limit this feature to private MUCs with a small number of participants, or to instead send the Receipt as a MUC-PM. - "headline": the Receipt message SHOULD have type="normal". - "error": this should not actually be possible, so the client SHOULD NOT (MUST NOT) respond. A client MUST be able to Process a Receipt message with a different type than the original Receipt Request message.
  143. jonas’ (quoting from Ge0rGs mail)
  144. dwd jonas’, Thanks.
  145. Ge0rG This is strawman wording, not carved in stone.
  146. jonas’ I think that’s sane, with the exception of the "headline" rule; I have no opinion on the "headline" rule
  147. dwd OK, so it's not clear to me that this is a bad set of words. I'd be happy to see that as a PR and we can vote on it.
  148. jonas’ I think that’s sane, with the exception of the "headline" rule; I have no opinion on the "headline" rule due to lack of data
  149. Ge0rG I wanted to initiate a discussion, specifically about _how_ to treat each of those, and whether this would be a ns-bumping change
  150. dwd Ge0rG, I think it's compatible with the existing XEP, and can only improve interop, so seems OK to me without a bump.
  151. Ge0rG Maybe what dwd said is the more sensible strategy: have all receipts be type=normal and rather fix MAM and Carbons
  152. Ge0rG I think we can all agree that a type=headline receipt doesn't make sense.
  153. dwd We're running over on the 5-minute slot here, though - I'll dig out that email and reply to it with some comments.
  154. jonas’ for some reason that mail was marked as read so I totally forgot about it
  155. Ge0rG dwd: awesome. I can't promise any activity in the next three weeks though.
  156. jonas’ replied, too
  157. dwd c) XEP-0308 (Last Message Correction) in MUC
  158. jonas’ Link Mauve, your slot
  159. jonas’ I guess this is in context of https://github.com/xsf/xeps/pull/736
  160. Ge0rG Link Mauve: the PR was rejected because everybody was wondering how you are going to combine limited back-history with strong guarantees
  161. Ge0rG Yes
  162. jonas’ quoting Link Mauve from above: 15:22:43 Link Mauve> Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.
  163. jonas’ quoting Link Mauve from above: 15:22:43 Link Mauve> Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.
  164. jonas’ i guess we can defer the discussion based on that?
  165. Link Mauve Indeed, that’d be my preferred course of action.
  166. Ge0rG I wanted to clarify the issue, but it's in the Council logs as well, obviously.
  167. Ge0rG Alright, let's defer
  168. dwd OK, so nothing on this yet. That's fine.
  169. dwd 4) Voting
  170. Kev Is there anything?
  171. dwd (Please do so, I think some expire today).
  172. jonas’ Link Mauve, you’re pending votes on: - https://github.com/xsf/xeps/pull/778 - https://github.com/xsf/xeps/pull/787 - https://github.com/xsf/xeps/pull/779
  173. Kev Ah, right.
  174. Ge0rG Link Mauve is owing me a vote or two
  175. dwd 5) Next Meeting
  176. jonas’ Link Mauve, you’re pending votes on: - https://github.com/xsf/xeps/pull/778 - https://github.com/xsf/xeps/pull/787 - https://github.com/xsf/xeps/pull/779 - https://github.com/xsf/xeps/pull/758
  177. dwd I think we're moving into the Time Of No Georg?
  178. jonas’ +1 wfm
  179. jonas’ +1w wfm
  180. Ge0rG dwd: right. I can't promise presence in the next two meetings.
  181. dwd +1wwfm2.
  182. Kev The interregnum!
  183. Kev Yeah, WFM.
  184. Ge0rG it might work on short notice though.
  185. Link Mauve Wfm too.
  186. dwd OK, great.
  187. dwd 6) AOB
  188. dwd I'll assume that we've covered everything.
  189. dwd 7) Ite, Meeting Est
  190. dwd And I numbered it right this time, Tedd.
  191. Kev Thanks all
  192. Ge0rG Thanks
  193. jonas’ \o/ thx
  194. Link Mauve Thanks. :)
  195. Link Mauve And now, to cast my votes!
  196. peter has joined
  197. Kev_ has left
  198. peter has left
  199. debacle has joined
  200. peter has joined
  201. peter has left
  202. peter has joined
  203. peter has left
  204. peter has joined
  205. peter has left
  206. Wojtek has joined
  207. Wojtek has left
  208. debacle has left
  209. lnj has left
  210. lnj has joined
  211. susmit88 has joined
  212. susmit88 has left
  213. susmit88 has joined
  214. susmit88 has left
  215. Wojtek has joined
  216. Wojtek has left
  217. dwd has left
  218. dwd has joined
  219. lnj has left
  220. dwd has left
  221. dwd has joined
  222. debacle has joined
  223. dwd has left
  224. dwd has joined
  225. dwd has left
  226. Wojtek has joined
  227. Wojtek has left
  228. dwd has joined
  229. dwd has left
  230. dwd has joined
  231. peter has joined
  232. dwd has left
  233. dwd has joined
  234. peter has left
  235. dwd has left
  236. dwd has joined
  237. peter has joined
  238. dwd has left