XMPP Council - 2021-02-17


  1. SouL has left

  2. neox has left

  3. stpeter has left

  4. stpeter has joined

  5. stpeter has left

  6. faith113 has joined

  7. faith113 has left

  8. paul has left

  9. Kev has left

  10. Kev has joined

  11. vaulor has joined

  12. Zash has left

  13. SouL has joined

  14. daniel has left

  15. daniel has joined

  16. Zash has joined

  17. paul has joined

  18. Tobias has joined

  19. Tobias has left

  20. Tobias has joined

  21. neox has joined

  22. Wojtek has joined

  23. debacle has joined

  24. mdosch has left

  25. mdosch has joined

  26. Zash has left

  27. adiaholic has left

  28. Zash has joined

  29. adiaholic has joined

  30. B has left

  31. B has joined

  32. SouL has left

  33. larma has left

  34. SouL has joined

  35. stpeter has joined

  36. Anas has joined

  37. Anas has left

  38. stpeter has left

  39. stpeter has joined

  40. B has left

  41. mdosch has left

  42. mdosch has joined

  43. B has joined

  44. stpeter has left

  45. aosan has joined

  46. stpeter has joined

  47. larma has joined

  48. stpeter has left

  49. aosan has left

  50. aosan has joined

  51. larma has left

  52. aosan has left

  53. aosan has joined

  54. aosan has left

  55. Sam has joined

  56. pep. has left

  57. jonas’

    1) Roll Call

  58. daniel

    Hi

  59. Ge0rG

    Hi

  60. Zash

    Hello

  61. Zash

    dwd?

  62. jonas’

    let’s start

  63. jonas’

    2) Agenda Bashing

  64. jonas’

    assuming no complaints

  65. jonas’

    3) Editor’s Update

  66. jonas’

    nothing to report

  67. jonas’

    4) Items for voting

  68. jonas’

    none that I know of, did I miss anything?

  69. dwd

    Oh, sorry, didn't notice.

  70. dwd

    Are we up to date with the data forms PR?

  71. Zash

    That's expiring .. now, right?

  72. jonas’

    yes it is

  73. jonas’

    what do you mean by "up to date"?

  74. dwd

    Have any of us voted?

  75. jonas’

    I did

  76. jonas’

    nobody else AFAIK

  77. jonas’

    (I voted -0 yesterday on-list)

  78. Zash

    There seems to be ongoing on-list discussions.

  79. dwd

    In that case, I'll vote +1. As far as I can tell, doing otherwise will break several implementations including anythign based on Smack.

  80. jonas’

    dwd, as-is or with s/MUST/SHOULD/?

  81. dwd

    jonas’, Personally I'll go with as-is. I think this is the original intent, and early implementations appear to follow it.

  82. jonas’

    OK

  83. jonas’

    FTR, what Drew describes on-list is exactly the behaviour of aioxmpp on the client side.

  84. dwd

    jonas’, I do appreciate others may disagree.

  85. jonas’

    we need at least two more +1s anyway

  86. dwd

    jonas’, FTR, if you're consuming that way it doesn't matter. Producing, it matters more. Forwarding, though and this seems flat-out wrong.

  87. Ge0rG

    there was a really long thread that I didn't catch up yet :(

  88. jonas’

    dwd, aioxmpp may very well produce forms, and that’s what I’m talking about here

  89. jonas’

    dwd, agreed though that forwarding shouldn’t touch such things and that the implementation of them has serious issues.

  90. Kev

    I don’t think breaking Smack is a motivation to do things, but I think creating the headers after the content is probably broken.

  91. daniel

    I see why it is desirable to have it come first. I don't see how the existing text has always intended to do this

  92. Zash

    The thread looks to me as if it has rough consensus in the +1 direction, so I'll vote +1.

  93. Kev

    And a forwarding entity that changes order is certainly somewhere between ‘broken’ and ‘I hope it’s a closed deployment where they understand what they’re doing’.

  94. jonas’

    daniel, agreed, too

  95. Kev

    daniel: Indeed, it seems like the Right Thing, it doesn’t look like the original text necessarily mandated it, but it’s fairly clear it was the intention.

  96. Kev

    Doesn’t it say something like “the data following the headers” or somesuch?

  97. aosan has joined

  98. Wojtek has left

  99. Ge0rG

    so we decide that it's okay to break implementations that don't follow that?

  100. dwd

    Kev, Yeah. I think it's not very clear, but the intent is there.

  101. Wojtek has joined

  102. dwd

    Ge0rG, Or else we decide its OK to break implementations that rely on it.

  103. Ge0rG

    dwd: right. but those implementations didn't have a written right to rely on it.

  104. jonas’

    so I’m really reluctant about the MUST because this is Final

  105. Ge0rG

    only a vague implication

  106. jonas’

    if it was Draft or Experimental, I’d say go with it

  107. Ge0rG

    still, I'm okay with making the vague implication a formal requirement

  108. jonas’

    and yeah, I did not read the text as "the order on the wire must be that" either, so it’s at least ambiguous

  109. daniel

    > if it was Draft or Experimental, I’d say go with it Yes. (obviously)

  110. Ge0rG

    what about adding a note about earlier versions of the XEP not strictly mandating order?

  111. jonas’

    but as this is Final… I think it needs more than just adding a MUST. I think this should have a good rationale and explanation of the change *inside the text*.

  112. Wojtek has left

  113. jonas’

    Ge0rG, yes, that

  114. dwd

    I'd also be OK with a SHOULD. That would still mean aioxmpp and ejabberd needed a bugfix though, so it's somewhat moot.

  115. Wojtek has joined

  116. dwd

    Ge0rG, Or at least, "Many implementations have in the past not strictly enforced this ordering. Implementations are therefore encouraged to be flexible about the rodering"

  117. Ge0rG

    so -1 for the MUST as-is, +1 for either MUST with an explanatory textbox, or +1 for SHOULD

  118. jonas’

    Ge0rG, would you be so kind to provide that text box?

  119. larma has joined

  120. Ge0rG

    "rodering" is a nice word.

  121. jonas’

    the editor normally would but they’re short(er than usual) on time currently

  122. dwd

    Ge0rG, My language, I can do what i want with it.

  123. daniel

    I think I can get on board with a should

  124. Zash

    sgtm

  125. daniel

    I mean after all it's not probably not that big of a deal either way in practice. (somebody jusz needs to fix their code)

  126. jonas’

    SHOULD + textbox?

  127. dwd

    daniel, Noting that SHOULD is not the same as MUST (BUT NOT REALLY), why is SHOULD OK here?

  128. jonas’

    I have the file open now… I’ll just make a patch

  129. daniel

    But should feels less bad when changing a final xep

  130. Kev

    “Many implementations”? :D

  131. Ge0rG

    > Older revisions of this XEP (before 2.11.1) did not contain an explicit requirement for the ordering between <reported> and <item>. Implementations are therefore encouraged to be flexible when processing incoming data.

  132. daniel

    dwd: feelings

  133. Ge0rG

    jonas’: ^

  134. aosan has left

  135. Ge0rG

    but given that the PR explicitly speaks about the "XML document", and we have an XML stream, and it's not clear whether those are meant to be the same, I would expect that once I receive an <item> on the stream, NO MORE <reported> ARE EVER ALLOWED AGAIN!1!1!

  136. dwd

    Kev, It's not clear to me how many implementations are actually affected on either side. But it's non-zero for both.

  137. jonas’

    proposed diff: https://paste.debian.net/hidden/7826dc53/

  138. jonas’

    oh, what Ge0rG said seems more reasonable

  139. jonas’

    updated patch: https://paste.debian.net/hidden/1749f7e9/

  140. dwd

    Either way, if we adding this, we should bounce it back to the list.

  141. jonas’

    should we?

  142. jonas’

    I consider the addition of the box editorial.

  143. Ge0rG

    jonas’: +1 for your diff

  144. dwd

    jonas’, Well, Editorial means we don't get to vote on it, not that the community shouldn't have an opportunity for feedback.

  145. jonas’

    updated: https://paste.debian.net/hidden/a8de2ed3/ (s#data#&lt;x/&gt;# to make it unambiguous)

  146. daniel

    > updated patch: https://paste.debian.net/hidden/1749f7e9/ +1

  147. Kev

    Do you mean the styling of a box around some text? That seems editorial. Adding some text about implementations and encouraging behaviour definitely isn’t :)

  148. jonas’

    dwd, ok, if you strongly feel so, we shall do that. I don’t see the necessity, given that the list wouldn’t have discussed this diff in the first place if we hadn’t brought it up anyway

  149. dwd

    jonas’, Well, that's a problem in itself, really, isn't it? :-)

  150. jonas’

    dwd, ok, let’s not open this can of worms. I’ll push my diff into flows branch (if I am allowed to, we’ll see) and bounce it back to the list then.

  151. dwd

    jonas’, (And I was going to open that can of worms in AOB actually).

  152. Zash

    I don't think I can handle any cans of worms today.

  153. jonas’

    I pushed a patch onto https://github.com/xsf/xeps/pull/1032, will write the mail asynchronously.

  154. jonas’

    we’ll thus "cancel" the vote and re-vote on the updated diff next week after list feedback?

  155. dwd

    +1

  156. jonas’

    (we don’t technically have to cancel, I’ll just -1 and we vote on the new diff)

  157. Zash

    +1

  158. jonas’

    -1 because the new diff looks better considering the current state of the world

  159. jonas’

    alright

  160. jonas’

    IWE is pretty much vetoed, so we can move on to the other formalities and AOB

  161. jonas’

    5) Pending Votes

  162. jonas’

    we did that already pretty umch

  163. jonas’

    6) Date of Next

  164. jonas’

    +1w wfm

  165. daniel

    +1w wfm

  166. Zash

    +1w wfm

  167. dwd

    +1wwfm

  168. Zash

    and Ge0rG?

  169. jonas’

    excellent

  170. jonas’

    that’s a quorum :)

  171. jonas’

    (mail sent)

  172. jonas’

    7) AOB

  173. jonas’

    I hear dwd has any

  174. jonas’

    I hear dwd has some

  175. dwd

    Just noting that the Data Forms discussion on list was very useful, but really only started once voting had begun, which feels pretty awkward - it'd be better to get these things discussed on the list first, and put on our agenda once they're "pre-discussed" so we can just vote.

  176. aosan has joined

  177. jonas’

    mmmhm

  178. jonas’

    I agree

  179. dwd

    I mean, especially when tweaking a Final spec, we seem to start list discussions a lot, and it feels like we're kind of starting the process at the wrong end.

  180. dwd

    (And ending up starting the clock a lot earlier than seems useful)

  181. jonas’

    it would be good if a few people who are interested in messing with CI infrastructures, webhooks and the likes would get on a sprint and improve the editor pipelines around such things.

  182. daniel

    Can or should we make standards subscribe to github PRs

  183. daniel

    Or something

  184. jonas’

    daniel, no.

  185. jonas’

    not without pre-filtering by the Editor

  186. jonas’

    (my opinion on that matter as a standards@ reader and editor)

  187. jonas’

    it would be nice if things which are tagged Needs List Discussion / Needs Council got annoucned automatically though

  188. jonas’

    I currently don’t have the capacities to work on that

  189. dwd

    Well, we could. Or we could simply tell Standards that things don't get onto the Council agenda unless someone asks for it on-list and therefore starts that discussion.

  190. jonas’

    dwd, that’s an interesting way to put it

  191. Zash

    Subverting the Github flow? I approve

  192. jonas’

    I can’t see any significant issue with that

  193. jonas’

    it would be nicer to automate things further so that people don’t have to do it and to e.g. auto-include links to the diff and maybe a rendered version (if/when we can have such things), but as a first iteration, I like dwds proposal.

  194. dwd

    It pushes workload onto the submitter of changes a bit, but encourages them to add a bit of rationale and bring people on side, too, so I feel it's mostly win.

  195. daniel

    I'm also somewhat fine with the current flow. Council gets to decide on easier, non controversial things and refers back to list as soon as we encounter something that demands more discussion

  196. daniel

    > It pushes workload onto the submitter of changes a bit, but encourages them to add a bit of rationale and bring people on side, too, so I feel it's mostly win. But yes that's also fine with me

  197. dwd

    daniel, Yes but it also forces us to arbitrate what is actually controversial in the first place, which seems suboptimal, espeically when we don't have an appeals process as such.

  198. aosan has left

  199. Kev

    If I say it, it’s not controversial. Anyone who disagrees is themselves trying to be controversial.

  200. dwd

    daniel, Gets fairly messy if it's one of us that makes a PR and convinces the rest of it's uncontroversial.

  201. jonas’

    Email proposal: Dear list, hat := council; The recent discussion about a change proposal on a Final spec has brought something to our attention which we think is a problem in our process. Specifically, the discussion about the change happened in the broader community only after the Council has started its voting process. If Council had been unanimous about the change, the change would’ve been applied immediately. In order to avoid lack of community participation in the future, the following change in our process is hereby established: Change proposals to XEPs which are under the control of Council do not get put on the Council agenda before there has been a thread on the standards mailing list. The thread is not required to have reactions or replies, but must be at least 48 hours old at the time the council session starts in order to be considered for voting. I hope you can see how this may improve the discussion culture and the process in general. If you have any questions or concerns, please raise them in reply to this email. We are happy to adapt this change if there are issues with it. kind regards, Jonas Schäfer (Council Chair)

  202. jonas’

    I don’t like the arbitration we have to do about whether something is controversial either, so I’d like to pilot this ASAP.

  203. dwd

    I'm not sure I like that choice of assignment operator, but otherwise it's all good. :-)

  204. jonas’

    :>

  205. Zash

    Sounds good

  206. jonas’

    Dear list, <hat role="council"> The recent discussion about a change proposal on a Final spec has brought something to our attention which we think is a problem in our process. Specifically, the discussion about the change happened in the broader community only after the Council had started its voting process. If Council had been unanimous about the change, the change would’ve been applied immediately. In order to avoid lack of community participation in the future, the following change in our process is hereby established: Change proposals to XEPs which are under the control of Council do not get put on the Council agenda before there has been a thread on the standards mailing list. The thread is not required to have reactions or replies, but must be at least 48 hours old at the time the council session starts in order to be considered for voting. I hope you can see how this may improve the discussion culture and the process in general. If you have any questions or concerns, please raise them in reply to this email. We are happy to adapt this change if there are issues with it. </hat> kind regards, Jonas Schäfer (Council Chair)

  207. jonas’

    dwd, is that better?

  208. Zash

    UNCLOSED TAG!!!!!

  209. jonas’

    Zash, not true!

  210. Zash

    oh

  211. Sam

    No root node, not a valid document.

  212. jonas’

    Sam, shush!

  213. dwd

    Heh. I read that as "<rat hole=...>" and thought it was very fitting. :-)

  214. Sam

    Maybe it's HTML.

  215. jonas’

    I’ll take a quick peek at the cake in the oven and hope that any other negative feedback is raised until I return, otherwise I’ll send that as-is after the session.

  216. dwd

    I'm not sure if it's Council Chair or Editor you want, mind, but seeing as you're both...

  217. Sam

    (jokes aside, I forget why I popped in today, but this is an interesting discussion and seems like a good idea, thanks all)

  218. jonas’

    dwd, yeah, I’m confused about that, too

  219. dwd

    (I mean, which role places things on the agenda officially?)

  220. jonas’

    dwd, the chair compiles the agenda

  221. jonas’

    I think

  222. jonas’

    but I don’t know

  223. dwd

    Nor will anyone else, so we're fine.

  224. jonas’

    I think so, too

  225. jonas’

    any other AOB?

  226. daniel

    None here

  227. Kev

    The Chair assembles the agendums. Definitely ;)

  228. jonas’

    alright

  229. jonas’

    8) Ite Meeting Est

  230. Zash

    Thanks jonas’, Tedd, all.

  231. dwd

    jonas’, Thanks, and sorry for my contributions to the overrun!

  232. jonas’

    thanks everyone, thanks dwd for that neat idea, thanks Tedd for the excellent minutes of the last session

  233. jonas’

    dwd, no worries!

  234. jonas’

    (from my side anyway)

  235. Kev

    Uhm.

  236. Kev

    I don’t think “Dear list,” is a valid XML preamble.

  237. jonas’

    Kev, Sam brought that up already, you’re late to the party

  238. jonas’

    :P

  239. Kev

    He can’t have.

  240. Sam

    Needs a mime type or something. Must be HTML, but autodetection is likely to lead to errors.

  241. Kev

    Because the mail only just arrived, and it’s the mail to standards that starts the discussion.

  242. Kev

    For Sam to have already raised it he’d have had to do so in the Council meeting, and that would mean the discussion in Council was before the mailing list thread, which isn’t how we do things.

  243. jonas’

    I’ll just step out of this for a while now

  244. Sam

    *facepalm* I was too fast.

  245. aosan has joined

  246. aosan has left

  247. aosan has joined

  248. aosan has left

  249. aosan has joined

  250. aosan has left

  251. aosan has joined

  252. daniel has left

  253. aosan has left

  254. aosan has joined

  255. daniel has joined

  256. daniel has left

  257. daniel has joined

  258. daniel has left

  259. daniel has joined

  260. adiaholic has left

  261. daniel has left

  262. daniel has joined

  263. adiaholic has joined

  264. daniel has left

  265. daniel has joined

  266. daniel has left

  267. daniel has joined

  268. sonny has left

  269. sonny has joined

  270. daniel has left

  271. daniel has joined

  272. daniel has left

  273. daniel has joined

  274. aosan has left

  275. daniel has left

  276. daniel has joined

  277. adiaholic has left

  278. adiaholic has joined

  279. aosan has joined

  280. aosan has left

  281. adiaholic has left

  282. stpeter has joined

  283. Tobias has left

  284. adiaholic has joined

  285. B has left

  286. B has joined

  287. Zash has left

  288. stpeter has left

  289. debacle has left