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. :)