XMPP Council - 2021-01-13

  1. jonas’ theadmiralty, explain your amusement please
  2. theadmiralty jonas’: the portion regarding zash and ipv6
  3. Ge0rG Looks like I'll be late to the party. I'm having fun yelling at incompetent consultants.
  4. mdosch > theadmiralty, explain your amusement please The Tedd style of writing boring facts down in an amusing way probably. 😃
  5. Zash Strategic brewing of coffee successful
  6. Ge0rG Coffee overflow.
  7. mdosch > Coffee overflow. Terrible. Get bigger coffee cups?
  8. mdosch > Coffee overflow. Terrible. Get bigger coffee cups!
  9. Ge0rG mdosch: I have a 370ml cup already. The overflow happens in my body
  10. Ge0rG Wow, the call ended just on time for the Council, only 27 minutes overtime.
  11. Zash 3 minutes of rest!
  12. jonas’ similar here
  13. jonas’ also fun: I still need to write emails
  14. jonas’ I’m going to be distracted, I’m sorry for that
  15. jonas’ 1) Roll Call
  16. daniel Hi
  17. Zash Hello
  18. jonas’ yay
  19. dwd Hiya
  20. Ge0rG is in a post-conference-call phone-call
  21. jonas’ explaining to a customer how the internet works and that we cannot inform them every time when they won’t be able to reach our site because some transit network fubar’d
  22. jonas’ *ahem*
  23. jonas’ 2) Agenda Bashing
  24. jonas’ any notes?
  25. dwd C sharp.
  26. jonas’ (this time with correct date!)
  27. Zash What Tedd pointed out earlier
  28. jonas’ yep, that
  29. jonas’ thanks
  30. jonas’ 3) Editor’s Update
  31. jonas’ - Proposed XMPP Extensions: - DOAP usage in XMPP - OMEMO Media Sharing
  32. jonas’ 4) Items for Voting
  33. Ge0rG I started reading the agenda multiple times, but then got distracted over and over again. Sorry.
  34. jonas’ 4a) Proposed XMPP Extension: DOAP usage in XMPP URL: https://xmpp.org/extensions/inbox/doap-usage-in-xmpp.html Abstract: This specification defines how XMPP projects can provide a machine-readable description of their abilities, and how external entities can interact with it.
  35. jonas’ I am on list, I did not have a minute of non-work time today yet.
  36. Zash Also on-list
  37. Ge0rG +1
  38. daniel are XEPs the right format to specify something that isn’t an extension?
  39. daniel i mean as a spec the document looks fine
  40. jonas’ daniel, if it defines how XEPs are to be used or referenced to, I think it’s borderline OK
  41. dwd I hadn't seen the submission. Not sure what track this should be. Happy for it to be a XEP, though - perhaps even Procedural?
  42. Zash Informational, not Standards Track, so I think that's fine
  43. Zash dwd, hmm
  44. jonas’ I’d suggest informational, it’s not a procedure of the XSF or the Council
  45. Zash or is it, if it touches on management of the website?
  46. dwd I'll got for "on-list" as far as a vote is concerned, but I'm heavily leaning toward +1.
  47. daniel +1
  48. jonas’ Zash, it doesn’t seem to
  49. dwd Zash, I can see arguments for it being STandards Track, as it's trying to define an interoperable wire format for the community.
  50. jonas’ depends on which wires, I suppose
  51. jonas’ but true, the typical Last Call / CFE questions would apply to this one
  52. jonas’ I suggest we bring that question up to the list
  53. Ge0rG I don't have a strong opinion either way
  54. Ge0rG However, with Standards Track, I'll start pondering about namespace versioning the schema.org schema
  55. jonas’ (sent the ProtoXEP mail just now, forgot that yesterday, so we have a thread to go on)
  56. jonas’ moving on
  57. jonas’ 4b) Proposed XMPP Extension: OMEMO Media Sharing URL: https://xmpp.org/extensions/inbox/omemo-media-sharing.html Abstract: An informal way of sharing media files despite limitations in the OMEMO encryption Note: We had this one as Standards Track in the past, but it was resubmitted as Historical.
  58. jonas’ the first fun question is whether Link Mauve got the IPR agreement from daniel to resubmit his work under a different Track
  59. Ge0rG What happened to the "this one as Standards Track in the past" document?
  60. jonas’ rejected by council
  61. jonas’ because evilness
  62. daniel didnt council back then decided that moving it to a different track isn’t enough?
  63. daniel because i vaguely remember offering to do this but it was rejected
  64. jonas’ 2018-05-30
  65. daniel so if we now +1 we overrule previous council decisions
  66. Ge0rG so technically it was submitted as Standards Track, but never landed there?
  67. jonas’ no, not 2018-05-30
  68. jonas’ still finding it
  69. Ge0rG on-list, I'll wait for the XEP-0001 taskforce to decide what our legitimate options are.
  70. Zash same, on-list
  71. jonas’ 2018-06-06
  72. daniel can we at least fix the example before publishing it
  73. daniel on list too
  74. jonas’ https://mail.jabber.org/pipermail/standards/2018-June/035135.html
  75. jonas’ finally, there you go. I think the gist is historical would be ok ("although not fond of")
  76. jonas’ any other votes?
  77. dwd So, Informational was rejected but Historical was not.
  78. jonas’ I am +1
  79. jonas’ (with any editorial fixes needed)
  80. jonas’ better to have it documented than not
  81. jonas’ dwd, do you want to vote?
  82. dwd I think we need to figure out what to do with the URL scheme. It feels like treading on another SDO's territory.
  83. jonas’ I think the document is rather clear on that
  84. Ge0rG I don't think there are any ambitions do establish that as a generic URL scheme
  85. dwd Right, but technically it would still need registering nonetheless.
  86. dwd OK, I'm on-list.
  87. Ge0rG dwd: I don't think so.
  88. dwd But I'll muse over this on-list instead of just being silent.
  89. daniel jonas’, what would be the best way to fix the examples?
  90. jonas’ daniel, send me a diff?
  91. jonas’ either as PR or mail or whatever works for you
  92. dwd daniel, FWIW, I'm perfectly happy to accept with broken examples and fix them.
  93. Ge0rG dwd: IMO, defining a non-standard URL scheme for the use in a specific, strictly defined context is fair game
  94. jonas’ I can incorporate (rebase/am) it to the released or the protoxep version, whichever works for me
  95. daniel oh right. i can just PR the inbox
  96. jonas’ We should all read https://tools.ietf.org/html/rfc7595
  97. daniel i was briefly confused.never mind
  98. jonas’ I am running out of time a little today, so I’ll push forward, sorry for that
  99. jonas’ 4c) Cancelled, thanks theTedd
  100. jonas’ 5) Pending Votes
  101. jonas’ a bunch of votes are pending on the MUC Mention Notifications ProtoXEP
  102. jonas’ does anyone want to cast votes here?
  103. jonas’ (it expires next week)
  104. Ge0rG Sorry.
  105. dwd I think I plus-oned that already.
  106. jonas’ dwd, that is correct :)
  107. jonas’ I assume noone wants to cast further votes here, moving on
  108. jonas’ 6) Date of Next
  109. jonas’ +1w wfm
  110. Zash +1w wfm
  111. daniel +1w wfm
  112. dwd +1wwfm
  113. Ge0rG +1w wfm
  114. jonas’ excellent
  115. jonas’ 7) AOB
  116. jonas’ any?
  117. dwd daniel, did you formally give permission to resubmit that OMEMO one?
  118. daniel no
  119. dwd daniel, OK, so unless and until you do that, we can't accept it anyway.
  120. daniel how would i do that?
  121. Ge0rG dwd: isn't IPR permission explicitly required when submitting a ProtoXEP?
  122. Ge0rG so even when the ProtoXEP is rejected, the permission remains?
  123. dwd Ge0rG, Yes, but we'll have asked Link Mauve, as I understand things, rather than daniel.
  124. jonas’ no, it is "upon acceptance", Ge0rG
  125. dwd Ge0rG, Ah, no. If we don't accept it, I assume that permission expires.
  126. Ge0rG Ah, thanks
  127. dwd Ge0rG, Or at least, I don't think it's safe to assume otherwise.
  128. jonas’ dwd, formally, Link Mauve is liable here because they accepted the XSF IPR when reproposing ;)
  129. dwd jonas’, True.
  130. jonas’ though we are now acutely aware that there is a problem
  131. jonas’ daniel, I think it’d be good and sufficient if you stated on-list that you are OK with resubmission in the protoxep thread.
  132. dwd daniel, To give permission, I assume just a message here or an email would be enough.
  133. daniel yes i'm fine with resubmitting it
  134. dwd daniel, Replying to the submission email would probably be most sensible. Assuming of course that you want to give permission.
  135. jonas’ daniel, thank you very much :)
  136. dwd Note for Tedd: Please make sure that's minuted.
  137. jonas’ any other AOB?
  138. daniel none here
  139. Zash I got nothing
  140. jonas’ thanks
  141. jonas’ 7) Ite Meeting Est
  142. daniel Thanks jonas’. Thanks everyone
  143. jonas’ gotta run, see you later
  144. Zash Thanks all
  145. Link Mauve daniel, do you accept me resubmitting your ProtoXEP under a different track?
  146. daniel i do. and that's already on the record
  147. Link Mauve Oh sorry.
  148. Link Mauve Perfect then. :)