XSF logo XMPP Council - 2019-04-24


  1. debacle has left
  2. Zash has left
  3. lnj has left
  4. Zash has joined
  5. Zash has left
  6. Neustradamus has left
  7. Neustradamus has joined
  8. peter has joined
  9. Zash has joined
  10. peter has left
  11. Zash has left
  12. Kev_ has joined
  13. Kev_ has left
  14. Neustradamus has left
  15. Neustradamus has joined
  16. vaulor has left
  17. vaulor has joined
  18. debacle has joined
  19. vaulor has left
  20. vaulor has joined
  21. lnj has joined
  22. vaulor has left
  23. vaulor has joined
  24. daniel has left
  25. daniel has joined
  26. Zash has joined
  27. Syndace has left
  28. Syndace has joined
  29. daniel has left
  30. daniel has joined
  31. daniel has left
  32. daniel has joined
  33. daniel has left
  34. daniel has joined
  35. daniel has left
  36. daniel has joined
  37. Kev Ok, I've remembered why the full-JID limit is in place, and it's an attempt to avoid issues with id collisions.
  38. Kev re: https://github.com/xsf/xeps/pull/784/files
  39. Kev I don't know if that should change our opinions at all.
  40. Kev For https://github.com/xsf/xeps/pull/778/files (I thought you could suggest text tweaks directly in github, but I don't see how now), under mandatory support I suggest adding the text """ While future versions of this specification (or other specifications) might use a different set of delivery rules, they would signify this by advertising a namespace other than "urn:xmpp:carbons:rules:0". """ , which I think matches what I suggested/requested last week. Ge0rG ^
  41. Ge0rG Kev: that's a great suggestion. I pondered about writing something along those lines, but then I realized that this is exactly why you have versioned namespaces in the first place, and thus considered it redundant
  42. Kev Half, yes. There's an ulterior motive there, which is that it's a get-out clause for letting us change things during Draft that otherwise would be more difficult :)
  43. Kev By mentioning that more changes might come later.
  44. Ge0rG Kev: https://github.com/xsf/xeps/pull/778/commits/e6cb1297f3a70b5f32af39250bd19951ec3c063d
  45. Ge0rG Kev: you claimed to have started a list discussion on https://github.com/xsf/xeps/pull/779 but I don't see anything.
  46. Ge0rG *hem* *hem*
  47. dwd Afternoon.
  48. dwd 1) Roll Call
  49. jonas’ .
  50. peter has joined
  51. Kev Here.
  52. Ge0rG .o/
  53. dwd Link? Or are we Linkless today?
  54. dwd Unlinked?
  55. jonas’ Unlinkly
  56. Kev Ge0rG: if it helps your search, I said this about 779: """ This seems a little backwards to me - it’s only saying the completely non-normative 'is a good practice’ for doing the right thing, while saying ’should’ (yes, I realise lower case) accept the wrong thing. Should we not SHOULD doing the right thing? /K """
  57. dwd Unlunk, then.
  58. dwd 2) Agenda Bashing
  59. Ge0rG let's put #779 on the agenda then?
  60. dwd OK, so Georg's suggested agenda plus #779.
  61. Ge0rG The only source of agenda items that I wanted to push onto everybody was what I came up with in the last week.
  62. Ge0rG I checked open PRs for "Council Needed", but don't know about proto XEPs or other issues
  63. dwd I'm in the office on a poor excuse for a computer, so I'm a bit rubbish today, but:
  64. dwd 3) Items for voting.
  65. dwd a) #778 (XEP-0280 rules bit)
  66. jonas’ +1 on #778
  67. Ge0rG I'm very much +1 on this.
  68. Ge0rG Please consider that it received another small update just one hour prior to this Meeting.
  69. dwd I think I'm +1, but I'll re-review properly if I have the time.
  70. Kev I'm +1 if I can have my text from earlier (bonus points if it also changes back to MAY when not using the feature ,but not blocking)
  71. dwd (But assume +1)
  72. Ge0rG dwd: _when_ you have the time?
  73. Kev Ah, my tweak's already in. +1 then.
  74. Ge0rG Kev: your text is already in
  75. dwd Ge0rG, I appreciate your optimism. I should do tonight.
  76. Ge0rG Actually, the SHOULD->MAY change is something we MAY discuss today
  77. dwd I think that's everyone +1, with Link Mauve on list.
  78. dwd And I'll suggest discussion later in AOB, if that's OK?
  79. Ge0rG With the new feature (does the name `urn:xmpp:carbons:rules:0` sound right to you?) I don't insist on SHOULDing the rules by default
  80. dwd b) #787 (Xep-0045, kill GC-1.0 with fire)
  81. Kev Ge0rG: I'd prefer SHOULD->MAY, but not a hill for me.
  82. Ge0rG +1 on #787
  83. jonas’ +1 on #787
  84. Kev urn...carbons:rules:0 seems fine to me.
  85. dwd +1 on this from me.
  86. Kev +1 on 787. I note that I'm not convinced it won't break anything, but progress and all that.
  87. dwd Kev, My conclusion was that it'll break things, but break them cleanly.
  88. Ge0rG Kev: prosody 0.11 was rolled out without GC1 and there was no Major Backlash
  89. Kev Major Backlash, reporting for duty.
  90. dwd c) #779 (I don't know what this is, even)
  91. Ge0rG We can rename it into GCexit if that suits you more.
  92. Kev Ge0rG: I'd like an extension, please.
  93. Ge0rG #779 is about an informative box in 0184 regarding the message @type
  94. Kev https://github.com/xsf/xeps/pull/779/files is what we discussed two weeks ago.
  95. dwd Yes, I was thinking this looked familiar.
  96. Kev My onlist response was > This seems a little backwards to me - it’s only saying the completely non-normative 'is a good practice’ for doing the right thing, while saying ’should’ (yes, I realise lower case) accept the wrong thing. Should we not SHOULD doing the right thing?
  97. Ge0rG https://mail.jabber.org/pipermail/standards/2019-April/036083.html
  98. Ge0rG Kev: I can uppercase it.
  99. Ge0rG but I won't uppercase the "must" in the MUC section
  100. Kev It's the other way around though, I think.
  101. Kev At the moment we're not should nor SHOULDing doing the right thing (matching type).
  102. Ge0rG because an implementation might want to realize MUC receipts as a MUC-PM
  103. Kev We're only shoulding what to do if you receive the wrong thing (different type).
  104. Kev I suggest s/It is a good proctice to/A client SHOULD/, I think.
  105. Kev (ignoring my typos)
  106. dwd I'll have a premptivee +1 on this. I'm pretty sure it's more or less right and that you two will figure outt the precise language here.
  107. Ge0rG Kev: that would be a normative change.
  108. Kev I think requiring the client to match non-matching types already is.
  109. Ge0rG I agree that it's the Right Thing, but I wasn't brave enough to introduce _that_
  110. Ge0rG Kev: prior versions didn't have any requirements on the incoming message type, so... no?
  111. Kev Hrmm.
  112. Ge0rG you could therefore argue that a client MUST accept different message types.
  113. Kev In that case, I'd suggest dropping that SHOULD back to a should, and brushing it under the carpet.
  114. Ge0rG Kev: I just added a patch to the PR containing the SHOULD.
  115. Kev Yeah, ok.
  116. Ge0rG Now you made me regret it.
  117. Kev Do we have enough +1s to pass if I +0? :)
  118. Ge0rG Yes.
  119. dwd jonas’ ?
  120. Kev +0 then.
  121. Ge0rG > PR #779 - XEP-0184: add a box about types and JIDs - https://github.com/xsf/xeps/pull/779 > Dave: [pending] > Georg: +1 > Jonas: +1 > Kev: [on-list] > Link: +1
  122. jonas’ still +1
  123. dwd Yeah, I think I voted +1 afterward/
  124. dwd And I'm still +1 whatever you guys decide on this.
  125. Ge0rG Is it an AOB to actually decide that?
  126. Kev The branch as-is is what's going in, I think.
  127. Kev And while I don't think it's quite right, I'm ok with that.
  128. dwd OK.
  129. dwd 4) Outstanding Votes.
  130. debacle has left
  131. dwd I have no clue today. But please check if you have any oustanding votes and vote them, outstandingly.
  132. dwd 5) AOB
  133. Kev I believe I'm completely up to date now, unusually.
  134. jonas’ mayeb we should re-discuss that PR I brought up on the list again
  135. Ge0rG I'm pending on #736 because we need feedback from Link Mauve
  136. Ge0rG jonas’: which one would that be?
  137. jonas’ -> https://github.com/xsf/xeps/pull/758 for next agenda maybe, I think it was technically vetoed but I’d like to re-open discussion on that one
  138. jonas’ because Kevs reasoning is unclear to me.
  139. Kev What was my reasoning? :)
  140. jonas’ here’s my respones to your reasoning: https://mail.jabber.org/pipermail/standards/2019-April/036059.html
  141. jonas’ here’s your original reasoning: https://mail.jabber.org/pipermail/standards/2019-March/035888.html
  142. Ge0rG nobody remembers, so move it to next week or have it added to AOB?
  143. Kev Ah, I remember, excellent.
  144. Kev This is in 5.4 https://xmpp.org/extensions/xep-0060.html#entity-metadata
  145. Kev Which says "If metadata is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like."
  146. Kev So I think if you add more options here, you SHOULD now include them (if you include any).
  147. Kev And so I think the claim that it doesn't change conformance wasn't right.
  148. dwd Right, and jonas’'s argument is that by the wording there, the access-model SHOULD already be included.
  149. Kev Ah, hrmm.
  150. dwd likes typing "jonas’'s" because of the fun punctuation.
  151. Kev Yeah, I buy that argument.
  152. dwd I suspect the practical solution would be to change the "it SHOULD" to "implementations are encouraged" in order to reflect reality.
  153. Kev Ah, no, because there is a registry in there for the form_type
  154. Kev And this is adding to it.
  155. Kev No?
  156. Ge0rG dwd: this is the worst way to improve an XEP.
  157. jonas’ it is, but it is still a configuration option
  158. jonas’ and it still should be reflected in there
  159. dwd Ge0rG, Indeed. But we then add a feature that says "I do this bit right".
  160. Ge0rG dwd: that's better. Or we write into the XEP that before version 1.23.42, the behavior was different and that the other end must cope with old entities.
  161. dwd Ge0rG, My way is more interoperable, I think.
  162. jonas’ I don’t think that applies in this case
  163. dwd Ge0rG, But yes.
  164. jonas’ because the set of configuration options is already rather fuzzy
  165. Ge0rG dwd: I'm not sure I agree.
  166. Kev The set of config options is, but the set of config options you're allowed to include in pubsub#metadata isn't.
  167. Kev As there's a registry for that.
  168. dwd Ge0rG, You can do both, mind.
  169. Ge0rG But this is all a meta discussion because 0060 would overload my capacity today.
  170. jonas’ Kev, a registry is mutable though
  171. dwd Kev, Registries are intended to be changed outside the XEP that defines them though.
  172. Kev Fair.
  173. Kev Yeah, I withdraw my -1.
  174. jonas’ I think we’d have to formally re-vote given that the voting period is looong over
  175. Kev Shove it on next week's agenda, that gives me 7 days to have an excuse to be belligerent.
  176. dwd jonas’, I don't think we need to, actually. The wording in XEP-0001 isn't clear, but the phrasing suggests that a COuncil person withdrawing their objection is sufficient.
  177. dwd Happy to revote is people *want*, mind.
  178. jonas’ I’d expect this to be more in hte bylaws than in '1
  179. dwd Happy to revote if people *want*, mind.
  180. jonas’ but I don’t care a lot, i’m fine with just kev withdrawing the vote and we go ahead
  181. Kev Votes are cheap, I think the precedent of publishing something that was long ago vetod is not one to set.
  182. dwd jonas’, Nope, standards process, not by-laws.
  183. dwd Fair enough, I'll stick it on next week then.
  184. jonas’ alright
  185. Kev Unless we want to +1 it now ,in which case +1.
  186. Kev But I'd rather just end the meeting on time :)
  187. dwd Yeah, even better.
  188. dwd Hah, too late:
  189. jonas’ not yet ;)
  190. jonas’ +1 wfm
  191. Ge0rG There are still AOBs.
  192. jonas’ +1w wfm
  193. jonas’ (too slow)
  194. Ge0rG I'm still +0
  195. dwd Well, given we've hit the half hour, I'll cut us short, but feel free to continue chatting.
  196. dwd 6) Next Meeting
  197. dwd +1W?
  198. jonas’ wfm
  199. dwd 7) Ite Meeting Est
  200. Ge0rG +2W for me.
  201. dwd Ge0rG, Noted.
  202. Ge0rG and it will be a +3W after that one.
  203. Ge0rG Technically, I'm not totally gone, but I'll most probably be in holiday mode away from a PC, and keeping up with Councils on a mobile is _hard_.
  204. dwd Ge0rG, Nice.
  205. jonas’ Ge0rG, so you’ll be able to vote on-list?
  206. Ge0rG so back to #779. I actually wanted to ask Council whether we want to move on with putting normative language on The Right Thing into the XEP, or whether the fig leaf note box is the best trade-off I can get.
  207. Ge0rG jonas’: given that I'll be gone for two weeks, and the two week voting period, I'm much confident that yes.
  208. jonas’ very good
  209. peter has left
  210. edhelas has joined
  211. edhelas hi
  212. edhelas so let's see the vote next week then :)
  213. Ge0rG sobs for his AOBs
  214. peter has joined
  215. debacle has joined
  216. peter has left
  217. daniel has left
  218. daniel has joined
  219. peter has joined
  220. daniel has left
  221. daniel has joined
  222. lnj has left
  223. peter has left
  224. debacle has left
  225. daniel has left
  226. daniel has joined
  227. peter has joined
  228. peter has left
  229. peter has joined
  230. dwd has left
  231. debacle has joined
  232. dwd has joined
  233. peter has left
  234. lnj has joined
  235. moparisthebest has left
  236. moparisthebest has joined
  237. debacle has left
  238. dwd has left
  239. dwd has joined
  240. dwd has left
  241. daniel has left
  242. Zash has left
  243. daniel has joined