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