XMPP Council - 2019-02-06


  1. Tokodomo has joined

  2. Tokodomo has left

  3. Remko has joined

  4. labdsf has left

  5. labdsf has joined

  6. Remko has left

  7. Zash has left

  8. labdsf has left

  9. labdsf has joined

  10. dwd has left

  11. Remko has joined

  12. Remko has left

  13. dwd has left

  14. Tobias has joined

  15. dwd has left

  16. Remko has joined

  17. grumpy has left

  18. Remko has left

  19. lnj has joined

  20. SouL has left

  21. lnj has left

  22. labdsf has left

  23. Remko has joined

  24. lnj has joined

  25. Remko has left

  26. Tobias has joined

  27. Tobias has left

  28. labdsf has joined

  29. Tobias has left

  30. labdsf has left

  31. labdsf has joined

  32. Remko has joined

  33. Remko has left

  34. Remko has joined

  35. Guus has left

  36. lnj has left

  37. lnj has left

  38. lnj has left

  39. lnj has left

  40. lnj has left

  41. lnj has left

  42. lnj has left

  43. lnj has left

  44. lnj has left

  45. lnj has left

  46. lnj has left

  47. lnj has left

  48. lnj has left

  49. lnj has left

  50. lnj has left

  51. lnj has left

  52. lnj has left

  53. lnj has left

  54. lnj has left

  55. lnj has left

  56. lnj has left

  57. lnj has left

  58. lnj has left

  59. lnj has left

  60. lnj has left

  61. lnj has left

  62. lnj has left

  63. lnj has left

  64. Zash has joined

  65. lnj has left

  66. lnj has left

  67. lnj has left

  68. lnj has left

  69. lnj has left

  70. lnj has left

  71. lnj has left

  72. lnj has left

  73. lnj has left

  74. lnj has left

  75. lnj has left

  76. lnj has left

  77. lnj has left

  78. lnj has left

  79. lnj has left

  80. lnj has left

  81. lnj has left

  82. lnj has left

  83. lnj has left

  84. lnj has left

  85. lnj has left

  86. lnj has left

  87. lnj has left

  88. lnj has left

  89. lnj has left

  90. lnj has left

  91. lnj has left

  92. lnj has left

  93. lnj has left

  94. lnj has left

  95. lnj has left

  96. lnj has left

  97. lnj has left

  98. lnj has left

  99. lnj has left

  100. lnj has left

  101. lnj has left

  102. lnj has left

  103. lnj has left

  104. lnj has left

  105. lnj has left

  106. lnj has left

  107. lnj has left

  108. lnj has left

  109. lnj has left

  110. lnj has left

  111. lnj has left

  112. lnj has left

  113. lnj has left

  114. lnj has left

  115. lnj has left

  116. lnj has left

  117. lnj has left

  118. lnj has left

  119. lnj has left

  120. lnj has left

  121. lnj has left

  122. lnj has left

  123. lnj has left

  124. lnj has left

  125. lnj has left

  126. lnj has left

  127. lnj has left

  128. lnj has left

  129. lnj has left

  130. pep. has joined

  131. lnj has left

  132. labdsf has left

  133. labdsf has joined

  134. dwd has left

  135. Tobias has joined

  136. Tobias has joined

  137. Tobias has left

  138. Tobias has left

  139. Tobias has left

  140. Tobias has left

  141. labdsf has left

  142. labdsf has joined

  143. Tokodomo has joined

  144. grumpy has joined

  145. grumpy has joined

  146. Kev

    Should be back in time for 4. Today's getting away from me, so sorry if I'm not.

  147. Guus has joined

  148. Guus has joined

  149. Guus has joined

  150. Guus has joined

  151. Guus has joined

  152. Ge0rG has joined

  153. Ge0rG

    dwd: https://github.com/xsf/xeps/pull/739 was merged, so it's technically a pre-advancement thing and not something to vote on. However, it's an indication of what changed in the XEP since it was last read by Council, so it might be good background info

  154. Ge0rG

    https://github.com/xsf/xeps/pull/752 is actually a submarine to make 0045 better.

  155. Ge0rG

    I hope that I'll be available in time for the Meeting, because my client scheduled a meeting at "around" 15:30

  156. Ge0rG

    So please excuse me if I'm late, and feel free to put "my" Agenda items to the end of the list

  157. zinid has joined

  158. Ge0rG

    He's not here yet, so I *am* going to be late.

  159. debacle has joined

  160. jonas’

    :(

  161. Ge0rG

    Maybe he'll be so late that we can have Meeting before. But somehow I have doubts about that.

  162. Ge0rG

    If you don't read anything from me, it's either xmpp.org connectivity or I'm AFK-busy.

  163. jonas’

    good luck

  164. Kev

    Been for a jog. Dripping. Can't sit like this, might be 2mins late.

  165. ralphm

    TMI

  166. dwd

    1) Wrap Call [healthier]

  167. dwd

    Who's here?

  168. jonas’

    I am

  169. Link Mauve

    o/

  170. dwd

    Kev's in the shower and will be doing the meeting wearing only a towel. Keep a hold of that image.

  171. dwd

    And Ge0rG has been swallowed by a meeting, I think.

  172. jonas’

    thank you very much, dwd.

  173. dwd

    jonas’, I'd say it's my pleasure, but really, it's not.

  174. Kev

    I'm here.

  175. intosi has joined

  176. Kev

    Don't worry, I don't have a towel.

  177. jonas’

    that doesn’t improve anything, Ke.

  178. jonas’

    that doesn’t improve anything, Kev.

  179. ralphm

    I'm here for PR 744

  180. zinid here for XOR

  181. dwd fetches the mind-bleach.

  182. jonas’

    oookay, maybe let’s get on with the agenda.

  183. dwd

    2) Agenda bashing

  184. dwd

    Thanks to jonas’ I think we caught everything.

  185. dwd

    Though Ge0rG said #739 wasn't really Council and had been merged (good).

  186. dwd

    So moving on:

  187. dwd

    3) Items for voting:

  188. dwd

    a) #739: XEP-0410: pre-LC and LC feedback https://github.com/xsf/xeps/pull/739

  189. dwd

    (Merged as noted)

  190. Kev

    (To save time, I'm going to be on-list on pretty much everything, sorry)

  191. dwd

    b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752

  192. jonas’

    postpone until Ge0rG is maybe there, dwd?

  193. dwd

    I'm fine with doing things a bit out of order in case Ge0rG manages to make it, yes. So parking this.

  194. jonas’

    same for c) then

  195. dwd

    d) #745: XEP-0234: Use <hash-used/> to signify the hash function being used, instead of an (invalid) empty <hash/> https://github.com/xsf/xeps/pull/745

  196. Link Mauve

    So, for this one I have a big set of changes stacked in a branch somewhere.

  197. Link Mauve

    I’d like to avoid bumping the namespace before merging those.

  198. dwd

    Link Mauve, Meaning what?

  199. Link Mauve

    As in, what is the content of these changes?

  200. jonas’

    Link Mauve, to be honest, I’ve been waiting for your changes for over a year now

  201. Link Mauve

    Yeah, and I for more than that.

  202. dwd

    Link Mauve, Meaning you want us to delay this?

  203. Link Mauve

    The addition of <hash-used/> was already a breaking change without a namespace bump, so we can probably do so once more, and then bump once I’m ready for pushing mine.

  204. Link Mauve

    dwd, or that yes.

  205. jonas’

    I don’t have a strong opinion either way.

  206. jonas’

    the :2 version is "broken" anyways due to what Link Mauve said.

  207. Link Mauve

    :5*

  208. dwd

    I think this does need a namespace bump. And I'm not happy about delaying it for PRs we don't have, sorry.

  209. ralphm

    release early, release often?

  210. jonas’

    the ~:2 (that’s hashes, not ft)~ :5 version is "broken" anyways due to what Link Mauve said.

  211. jonas’

    dwd, NS-bumping Jingle-FT is meh though

  212. dwd

    jonas’, What do you mean?

  213. jonas’

    (NS-bumping *anything* is, but file transfer is particularly frustrating when it fails in non-obvious ways)

  214. jonas’

    Link Mauve, how realistic is it that you get your changes in order ’til next meeting?

  215. Link Mauve

    dwd, it’s used in quite a lot of places already, has many implementations, bumping the namespace temporarily sounds indeed meh.

  216. Link Mauve

    jonas’, I’ll put that as a high priority, so somewhat likely.

  217. dwd

    You may have a point, actually - the hash -> hash-used change means that an application expecting hash simply sees no hash at all.

  218. dwd

    Which is allowed by the spec. So I can live without the namespace change on that basis.

  219. dwd

    Anyway votes:

  220. dwd

    Kev, assuming on-list.

  221. jonas’

    I’m +1 on this without namespace change

  222. jonas’

    (-1 with namespace change)

  223. Kev

    Yes, on-list please.

  224. dwd

    I'm +1, I think.

  225. dwd

    Link Mauve, ?

  226. Link Mauve

    I’m +1 without namespace change.

  227. dwd

    OK.

  228. dwd

    e) Adopt Proposed XMPP Extension: XMPP Over RELOAD (XOR) Abstract: This specification defines an XMPP Usage of REsource LOcation And Discovery (RELOAD). The XMPP usage provides an ability for XMPP clients to discover other peers' location through the peer-to-peer overlay. Once a peer location is determined, the RELOAD AppAttach method is used to establish a direct connection between peers through which XMPP streams are exchanged. https://xmpp.org/extensions/inbox/xor.html

  229. jonas’

    I have no knowledge about RELOAD.

  230. Ge0rG .o/

  231. Neustradamus has joined

  232. jonas’

    Ge0rG, wb

  233. dwd

    I'm +1 on this. (I don't know more about RELOAD than the abstract of the RFC says, but it seems believable)

  234. jonas’

    I’d also like to mention that the XEP contains stuff which definitely does not belong into standards track

  235. Link Mauve

    I skimmed through it, read what zinid said about this protocol a while ago on conversations@ and am +1 on the basis that it looks good and sounds like an interesting proposal.

  236. dwd

    Ge0rG, To save you skimming back, we've shuffled the order form the agenda to put the '410 stuff at the end.,

  237. jonas’

    specifically, in §8.2: > The root certificate of the overlay MUST be created by the XSF. All intermediate authority's certificates MUST be signed by this root certficate.

  238. jonas’

    I don’t think we can accept this without Board involvement.

  239. Link Mauve

    But I don’t know much about RELOAD itself.

  240. Ge0rG

    jonas’: not even as Experimental?

  241. jonas’

    Ge0rG, not even as experimental

  242. dwd

    jonas’, It's Experimental, in fairness, but yes, it might need splitting for that basis.

  243. zinid

    if only I knew in what I should split it

  244. jonas’

    ralphm, if you happen to be around, a quick suggestion on this?

  245. ralphm

    Yeah, I'm thinking

  246. jonas’

    zinid, anything where it says "the XSF has to" needs to be removed, I think

  247. zinid

    where is the pattern for writing proposals for Board?

  248. Ge0rG

    I think that a wire format for exchanging CSRs and CRTs between XMPP entities, based on the entity JIDs, would be a welcome addition and solve the *technical* issue.

  249. jonas’

    zinid, same format, but different track. it needs to be different documents.

  250. ralphm

    I think it is kind of weird to have the XSF as the only entity to set up something like this.

  251. dwd

    zinid, Could you note that it requires a single CA, and then create a distinct XEP you define an XSF-based CA?

  252. jonas’

    (i.e. you switch "Standards TRack" to "Procedural" or something and describe how the CA should operate)

  253. zinid

    jonas’, I can of course remove that from the protoxep, easily, but that doesn't solve the problem

  254. jonas’

    zinid, what dwd says is correct and sensible.

  255. Ge0rG

    why XSF-based at all? It can be completely external as long as somebody documents it as the trust root for RELOAD-XMPP

  256. dwd

    zinid, The problem is that it requires a single CA? Or simply signed certificates?

  257. zinid

    dwd, only signed

  258. zinid

    by trusted CA

  259. ralphm

    I.e. the greater XMPP network is not a thing that is, or should be, controlled by the XSF?

  260. dwd

    zinid, Right. So the practical problem is that nobody signs end-user EE certs for jids?

  261. zinid

    dwd, yes

  262. zinid

    also, "trusted" in the sense that the CA should not produce massive amount certificates for attackers

  263. zinid

    *of certificates

  264. zinid

    that's the only requirement

  265. dwd

    zinid, OK. On that basis, I think it'd be best to note that requirement, and then remove the XSF-CA part (and if you want, submit that as a different protoXEP for the Board to consider).

  266. zinid

    okay for me

  267. jonas’

    zinid, I understand that certificates are needed here. Could you replace 8.1 and 8.2 with something more generic, leaving the XSF out of that, and make a follow-up document where you describe what’s necessary, on a procedural level, to make this work securely?

  268. jonas’

    ah, yes that

  269. zinid

    jonas’, yes, I will

  270. jonas’

    excellent

  271. zinid

    so reject it, will be ready to the next meeting

  272. jonas’

    zinid, fine by me

  273. dwd

    zinid, Sounds good. In that case I'll -1 this on the expectation that a new submission will pass.

  274. jonas’

    I’m -1 on the basis that the presented ProtoXEP has Procedural content which needs to be acked by Board.

  275. zinid

    (probably you will have some time for RELOAD itself, it's very good RFC :) )

  276. Link Mauve

    Yup, -1 waiting for the next version. :)

  277. jonas’

    so that’s sorted

  278. ralphm

    jonas’: I don't agree this is a requirement for rejecting it as experimental.

  279. ralphm

    I do agree that Board should be involved if we need to setup a CA.

  280. dwd

    I'd rather the Board chose whetheror not to adopt an XSF-CA document.

  281. jonas’

    I agree with dwd.

  282. dwd

    f) #744: XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft https://github.com/xsf/xeps/pull/744

  283. ralphm

    dwd: I agree with that of course

  284. Ge0rG

    I'm pretty sure the XSF doesn't want to participate in the CA ~racket~ business.

  285. Link Mauve

    dwd, +1, but IIRC we already agreed on this change a few weeks ago.

  286. ralphm

    dwd: I'm not sure if adopting it as experimental means we're going to do it, though.

  287. Link Mauve

    I’m fine with the wording of it.

  288. ralphm

    On 744, I understand that Kev had issues with it

  289. jonas’

    +1 on #744

  290. Kev

    Let me remind myself.

  291. ralphm

    Go ahead

  292. Ge0rG

    +1 on #744

  293. Kev

    Oh, yes, so this means that someone can automatically take authorship of a spec by proposing it.

  294. Ge0rG

    Oh. good point.

  295. dwd

    +0 on this. I think in practise it doesn't matter, but the authorship change is curious.

  296. jonas’

    oh, I totally missed that part of the sentence O_O

  297. Kev

    I think that's wrong, and asking for it to be advanced, and changing authorship, should be independent things.

  298. Ge0rG

    But how else do we want to handle it?

  299. jonas’

    I hate reading diffs

  300. jonas’

    I agree with Kev

  301. dwd

    Ge0rG, Anyone can ask for a Deferred doc to be advanced seems fine.

  302. Ge0rG

    Do we want to accept Proposal from anybody?

  303. Ge0rG

    dwd: even without an author?

  304. jonas’

    Ge0rG, no, we still vote on it

  305. jonas’

    Ge0rG, yes, if a XEP is ready for Draft, it doesn’t matter if the author is still around

  306. dwd

    Ge0rG, We do, under this PR. It's just that this PR *also* magics the proposer into a XEP Author.

  307. jonas’

    afterwards, the Council will be the gatekeeper for changes anyways

  308. Ge0rG

    I kind-of-like that you can't Propose without commiting to maintain it.

  309. jonas’

    yeah, I don’t like that authorship change, I think it’s unnecessary

  310. Kev

    dwd: And the way I read it, also bumping off the old Author.

  311. dwd

    I am strictly ambivalent to it.

  312. Kev

    Or, at least, it's not clear that it /doesn't/ mean that.

  313. ralphm

    Kev: my thinking was that accepting changing ownership would be up to the Editor

  314. Ge0rG

    -1 as it is +1 with <del>, thereby taking up the role of XEP author</del>

  315. Tokodomo has joined

  316. dwd

    Kev, I don';t think we explicitly have to kill them.

  317. Kev

    ralphm: I don't think that's what this text says.

  318. peter has joined

  319. jonas’

    -1 as it is +1 with <del>, thereby taking up the role of XEP author</del>

  320. ralphm

    I am not saying it changes the Author, it takes up the role for the purpose of moving it in the process as further described.

  321. jonas’

    if the Approving Body (AB) decides that a specification should have an active author to advance, they can still require that and make the proposer author, if needed.

  322. dwd

    ralphm, That's definitely not what it says.

  323. ralphm

    If that's not clear (or you think that's actually not different), that was at least my attempt.

  324. jonas’

    ralphm, oooh, I see the intent now

  325. jonas’

    maybe ", thereby taking up the role of the XEP author for the purpose of proposing"?

  326. Kev

    I think just removing ", thereby taking up the role of XEP author" is easiest.

  327. dwd

    Right, I think the objections are clear.

  328. Ge0rG

    ralphm: what responsibilities does an author have for the purpose of moving a XEP in the process?

  329. ralphm

    The problem is that you need an XEP Author to process LC feedback

  330. dwd

    Note that, as a point of order, we don't get a binding vote on this as Council since the Approving Body is Board.

  331. dwd

    ralphm, Oh, that is actually a good point.

  332. Kev

    ralphm: Sure, but Council can look at getting a new Author where needed.

  333. jonas’

    ralphm, indeed a good point

  334. Kev

    And Deferred and Abandoned are not equivalent.

  335. Ge0rG

    Council can also (theoretically) incorporate LC feedback.

  336. dwd

    Kev, Right, but ralphm's suggestion mean that if you propose a Deferred XEP, you are taking responsibility for it.

  337. jonas’

    ralphm, can you put some wording together which makes this clear? making the proposer responsible for processing (at least by making concrete proposals for) the LC feedback would be good, methinks

  338. Ge0rG

    But I think it makes sense to put that burden on the Proposer.

  339. ralphm

    dwd: but only if there's no active Author to collaborate with.

  340. jonas’

    this is, by default, limited to processing the LC feedback, in my mind.

  341. Kev

    dwd: Yes - but I think automatically making someone Author is the wrong thing.

  342. jonas’

    I think thath makes a lot of sense

  343. jonas’

    I think that line of thinking ("Proposer manages LC feedback if author(s) are unavailable") makes a lot of sense

  344. jonas’

    I think that line of thinking ("Proposer manages LC feedback (and only that if no other agreements with the AB exist about that) if author(s) are unavailable") makes a lot of sense

  345. ralphm

    And indeed, my intent was that in case of abandonment, somebody proposing to move further would be interested in taking up ownership.

  346. dwd

    Or simply that the Proposer may be required to take the role of Author during Last Call.

  347. ralphm

    If proposer is allowed to process LC feedback, why doesn't that make him an author of sorts?

  348. Kev

    I think we're at the stage of some new text being a good idea, and may as well move on.

  349. Ge0rG

    dwd: and after Last Call, until all feedback is incorporated

  350. Ge0rG

    We are also overdue with our time and underdue with our Agenda.

  351. dwd

    ralphm, Do you have enough feedback from us to clarify the text?

  352. peter

    This sounds a bit like the Document Shepherd role at the IETF.

  353. dwd

    Ge0rG, Indeed.

  354. dwd

    peter, That also.

  355. ralphm

    dwd: I don't know yet how to process the feedback into new text

  356. Kev

    ralphm: largely because I forsee that someone is going to go through every deferred XEP, propose it for advancement, and get their name at the top of it automatically because of it.

  357. ralphm

    peter: I'm not familiar with that concept

  358. jonas’

    maybe take the details to the list?

  359. dwd

    ralphm, OK - but I'm going to move on, because I think we're just getting bogged down in detail.

  360. dwd

    g) #746: XEP-0060: Add missing @publisher in pubsub schema https://github.com/xsf/xeps/pull/746

  361. ralphm

    Kev: but if somebody who has abandoned authorship isn't involved, but the document changes anyway, isn't that a problem, too?

  362. Link Mauve

    g) I’m obviously +1, as I am its author.

  363. dwd

    I'm +1 on '746, this looks satrightforward.

  364. peter

    ralphm: https://www.ietf.org/blog/iesg-statement-document-shepherds/

  365. jonas’

    +1

  366. dwd

    ralphm, peter - sorry, we've moved on.

  367. peter

    yep

  368. ralphm

    dwd: I'd still like to somehow discuss details with council

  369. peter

    that's why I prefaced with `ralpphm:` :P

  370. Ge0rG

    +1

  371. peter goes back to $dayjob

  372. ralphm

    peter: thanks!

  373. dwd

    h) #747: XEP-0084: Bump the maximum of @width and @height to 65535 https://github.com/xsf/xeps/pull/747

  374. Link Mauve

    +1 too, for the same reason.

  375. Ge0rG

    This is a schema change, technically it requires a namespace bump.

  376. jonas’

    +1, it doesn’t change any normative part, and is probably an oversight of <revision> <version>0.11</version> <date>2007-07-25</date> <initials>psa</initials> <remark><p>Removed image size requirements.</p></remark> </revision>

  377. Link Mauve

    Ge0rG, uh, why?

  378. dwd

    I'm going to have to be on-list for this one. I'm going to have to dig a little.

  379. dwd

    Mostly on the question of whether Ge0rG is right or not.

  380. Link Mauve

    Do we have any mention that schemas are normative that way?

  381. Ge0rG

    Link Mauve, jonas’: if you followed the old schema and implemented it as u8, you'll end up overflowing your data field

  382. Kev

    Schemas are non-normative in XEPs.

  383. dwd

    We have usually held within the XSF that schemas are non-normative.

  384. jonas’

    Ge0rG, if you parse XML strictly by schema without validating it, you’re doing it wrong

  385. Link Mauve

    Kev, that’s what I remember too.

  386. Link Mauve

    jonas’, and if you do validate it, as it is you will reject way too many otherwise valid images.

  387. Ge0rG

    I'm not saying I'm -1, just interpreting the consequences of the change.

  388. dwd

    Ge0rG, Are you -1 as-is, or not, then?

  389. jonas’

    (please don’t namespace-bump avatars...)

  390. Ge0rG

    dwd: +1 because I want to see the world burn

  391. dwd

    :-)

  392. jonas’

    🔥

  393. dwd

    Looping back to the beginning, then.

  394. Ge0rG

    Also Link Mauve owes me a no-namespace-bump XEP change then :D

  395. dwd

    b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752

  396. Ge0rG

    the background of #752 was a list discussion, of which I concluded that it would be great to have an application-specific <not-an-occupant/> or maybe <not-in-room/> condition in MUC

  397. jonas’

    +1 on this, or any other of the commonly-encountered RFC 6120 stanza error condition for accompanying not-an-occupant

  398. dwd

    Is there any reason why this isn't using the `@by` attribute of the error element?

  399. Ge0rG

    But I didn't want to PR MUC yet.

  400. Ge0rG

    But really I want this new condition added to 0045.

  401. jonas’

    dwd, that’s a good addition actually

  402. Ge0rG

    dwd: you mean the example?

  403. Link Mauve

    Is there any reason this isn’t part of 0045 instead?

  404. Ge0rG

    Link Mauve: namespace-bumping-MUC

  405. Zash

    The entire thing?!

  406. jonas’

    dwd, but having a distinct muc-specific <not-an-occupant/> in addition is a good thing

  407. Ge0rG

    Zash: all of it

  408. dwd

    Ge0rG, So do it a MUC extension that adds it under a different namespace?

  409. jonas’

    urn:xmpp:muc:1!

  410. Ge0rG

    dwd: why not have a feature for it on MUC and use the MUC namespace?

  411. dwd

    Ge0rG, <feature var="urn:xmpp:muc:errors:0"/><!-- sends application-specific errors for MUC -->

  412. Ge0rG

    Ah, and use that NS.

  413. dwd

    Ge0rG, Using another XEP's namespace doesn't really sit well with me.

  414. Link Mauve

    A feature sounds like the way forward.

  415. Ge0rG

    dwd, Link Mauve: the specific reason for having this in 0410 was because I wanted to have this discussion, but didn't want to further delay 0410

  416. dwd

    I agree this is useful (though also, @by needs more implementation and use), but it's useful and generic.

  417. Link Mauve

    +1

  418. debacle has left

  419. Ge0rG

    if we add <not-an-occupant xmlns="urn:xmpp:muc:errors:0"/> into 0410, we are now defining MUC errors in a XEP that's actually doing something different.

  420. dwd

    So, I think overall this is a -1 from me, sorry. That said, I don't think this needs to mean '410 needs delaying.

  421. Ge0rG

    What about jonas’ writing a separate Application Specific Errors for MUC XEP?

  422. jonas’

    why me

  423. Ge0rG

    jonas’: you brought that mess upon me.

  424. jonas’

    dammit

  425. Ge0rG

    I add a @by into 0410, and we publish it.

  426. jonas’

    I don’t have a weekend this week, so I can’t promise anything

  427. Ge0rG

    is anybody against having @by in 0410?

  428. jonas’

    @by is a good thing here

  429. dwd

    Ge0rG, jonas’ - votes?

  430. jonas’

    I’m +0

  431. Ge0rG

    and I'm -1 on #752, despite being the author

  432. jonas’

    ha

  433. Ge0rG

    because it needs its own XEP.

  434. Link Mauve

    ^^

  435. dwd

    Awesome.

  436. Ge0rG

    Thank you for the discussion, everyone.

  437. dwd

    Great when people reject their own stuff. :-)

  438. dwd

    c) Advance XEP-0410 to Draft https://xmpp.org/extensions/xep-0410.html

  439. Ge0rG

    The main part of the PR was this: > Please have a Council discussion.

  440. Ge0rG

    +1 to advance 0410 (with a @by added into the error)

  441. dwd

    Same for me - +1 (with @by)

  442. jonas’

    +1 to advance 410, with @by added

  443. Link Mauve

    Same here, +1.

  444. Ge0rG

    jonas’: shall I make a PR or will you do it with your Editor Hat on?

  445. jonas’

    Ge0rG, please make a PR

  446. dwd

    OK. I think we're done with items for voting.

  447. jonas’

    Ge0rG, I like to have more eyes (even if it’s just four) on it before merging stuff

  448. dwd

    4) Outstanding Votes

  449. dwd

    If anyone has anything, please do so on list given the overrun.

  450. dwd

    5) Next Meeting

  451. dwd

    Same time next week?

  452. jonas’

    +1w is ok for me

  453. Link Mauve

    Same.

  454. dwd

    6) AOB

  455. dwd

    (Please no)

  456. jonas’

    Thanks to Tedd Sterr for doing the minutes all the time and the vote summaries.

  457. Ge0rG

    +1 to that

  458. dwd

    Yes, that is amazingly helpful.

  459. jonas’

    tremendously helpful in both of my roles here

  460. Ge0rG

    I have a proto-proto-XEP about Simple Encryption for XMPP in the works, but I don't dare Ask Council.

  461. dwd

    It'd be great if they joined as a member, though that'd involve a real name.

  462. Kev

    Indeed, yay to minutes etc.

  463. dwd

    Assuming no other business...

  464. dwd

    7) Ite, Meeting Est

  465. Kev

    I have a non-AOB AOB.

  466. Kev

    Please let's keep to 30mins.

  467. dwd

    Kev, I generally agree. But we had 7 items to vote on, and I infinitely prefer voting in-meeting to voting on-list where possible.

  468. jonas’

    dwd, we could’ve moved the remaining items to +1w

  469. Kev

    Quite.

  470. jonas’

    I don’t want to cut down on in-meeting discussions, I think those are valuable

  471. dwd

    Sure, but I think the first meeting after Summit is always going to be busy - lots of energy, plus a missed meeting the week before.

  472. Ge0rG

    jonas’: https://github.com/xsf/xeps/pull/754

  473. dwd

    So, you know, sorry-not-sorry. :-)

  474. Kev

    I think the likely outcome is the opposite of the desired one if it becomes a habit.

  475. Kev

    Which is all votes going to onlist.

  476. Ge0rG

    Kev: all votes or just the ones cast after the first 30 minutes? ;-)

  477. Kev

    Once upon a time Council meetings were a mess, usually ran over, stuff was invariably onlist.

  478. Kev

    We eventually sorted that out and got down to sensible 30 minute meetings, with most stuff happening during them.

  479. Kev

    I'm keen not to go back.

  480. Kev

    And I'd rather punt items to the following week than have people sitting appearing to be in the meetings but actually not because they're doing something else once the meeting overruns.

  481. Ge0rG

    I'm really sorry for being late.

  482. Kev

    Stuff happens.

  483. Kev

    I was late too.

  484. Kev

    I don't think either were what caused the running over.

  485. ralphm waves

  486. Guus has joined

  487. zinid has left

  488. labdsf has left

  489. pep. has joined

  490. Tokodomo has left

  491. Tokodomo has joined

  492. Tokodomo has left

  493. Tobias has joined

  494. intosi has left

  495. intosi has joined

  496. labdsf has joined

  497. debacle has joined

  498. Tobias has left

  499. Guus has left

  500. ivucica has left

  501. ivucica has joined

  502. Zash has left

  503. grumpy has joined

  504. Guus has joined

  505. debacle has left

  506. labdsf has left

  507. labdsf has joined

  508. dwd has left

  509. labdsf has left

  510. labdsf has joined

  511. Tokodomo has joined

  512. Link Mauve has joined

  513. Tokodomo has left

  514. Link Mauve has joined

  515. Zash has left

  516. labdsf has left

  517. labdsf has joined

  518. peter has left

  519. lnj has left

  520. lnj has left

  521. lnj has joined

  522. lnj has left

  523. lnj has left

  524. lnj has joined

  525. Guus has left

  526. Guus has joined

  527. Guus has left

  528. Tokodomo has joined

  529. Guus has joined

  530. lnj has left

  531. lnj has left

  532. lnj has joined

  533. Link Mauve has left

  534. peter has joined

  535. Guus has left

  536. Tokodomo has left

  537. Guus has joined

  538. Remko has left

  539. Link Mauve has joined

  540. grumpy has left

  541. Guus has left

  542. Guus has joined

  543. grumpy has joined

  544. Guus has left

  545. oli has joined

  546. Tobias has joined

  547. Zash has left

  548. Guus has joined

  549. Link Mauve has joined

  550. pep. has joined

  551. Link Mauve has joined

  552. SouL has left

  553. zinid has left

  554. peter has left

  555. oli has joined

  556. lnj has left

  557. lnj has left

  558. lnj has left

  559. pep.

    > dwd> It'd be great if they joined as a member, though that'd involve a real name. Would it? There's no reaction on the LC for 345. I am the only one to have replied to it?

  560. lnj has joined

  561. Link Mauve has joined