XMPP Council - 2020-11-18


  1. daniel

    Hi

  2. Zash

    Hey

  3. dwd

    Ho

  4. dwd

    (From new house)

  5. Zash

    jonas’, forgotten about the meeting or nah?

  6. Ge0rG

    good morning everyone!

  7. Zash

    Sun went down hours ago, it's night now.

  8. Ge0rG

    Zash: set your clock to UGT

  9. Zash

    Do we have a chair?

  10. Ge0rG

    well, given an excellently prepared agenda, somebody can step in

  11. dwd

    I have a chair, thankfully. Though no desk, yet.

  12. Ge0rG

    1) Roll Call

  13. dwd

    Oh, jonas’ said he might forget.

  14. Ge0rG

    looks like we are missing jonas’

  15. Zash

    4/5

  16. Ge0rG

    everybody else is here, great!

  17. Ge0rG

    2) Agenda Bashing

  18. Ge0rG

    are there any things to add?

  19. Ge0rG

    3) Editor’s Update

  20. Ge0rG

    Editor's been very busy, we have some things to vote on today.

  21. Ge0rG

    4) Items for voting

  22. Ge0rG

    please note that our term is closing, and we need to submit all votes until November 24th.

  23. jonas’

    hahaha

  24. Ge0rG

    Can we manage that?

  25. jonas’

    yeah, it happened

  26. jonas’

    I was pulling cookies out of the oven just now

  27. jonas’

    here I am

  28. Ge0rG

    welcome, jonas’!

  29. jonas’

    sorry for the delay, thanks for taking over, Ge0rG

  30. Ge0rG

    jonas’: do you want to have the chair hat back?

  31. dwd

    Ge0rG, Maybe it's a hat chair?

  32. jonas’

    Ge0rG, works for me

  33. jonas’

    let’s see what happens to our votes :)

  34. Ge0rG

    I was just going to ask if everbody silently agrees with submitting all pending votes until November 24th.

  35. jonas’

    4a) Proposed XMPP Extension: File metadata element URL: https://xmpp.org/extensions/inbox/file-metadata.html Abstract: This specification defines a generic file metadata element to be used in other specifications.

  36. jonas’

    Ge0rG, let’s just try and hope I don’t have to read bylaws or something

  37. dwd

    This one got some discussion on list already, and seems fine, so +1.

  38. jonas’

    did it?

  39. Zash

    Oh?

  40. daniel

    +1

  41. dwd

    Ages ago, IIRC.

  42. jonas’

    ah

  43. jonas’

    I am +1, though I do have remarks I’ll suggest to the authors on-list

  44. Zash

    Got a reference to this previous discussion?

  45. dwd

    Or at least, it all looked familiar so I assumed I'd seen it before.

  46. Ge0rG

    this looks like it's copying the <file> element out of XEP-0234 for the sake of copying the <file> element out of XEP-0234. Am I missing something?

  47. Zash

    Yes

  48. Zash

    (so no)

  49. jonas’

    Ge0rG, pretty much that

  50. jonas’

    the idea is to have it separate for use in other specs and not bound to the '234 namespace, IIRC

  51. Zash

    +1

  52. Ge0rG

    what would be the way forward when we ever have to bump file-metadata? Will a client send two <file> elements with different namespaces?

  53. Ge0rG

    Well, given that 0234 is deferred, I think it's well worth a try, so +1

  54. Zash

    I'm not entirely convinced that another XEP fixes anything

  55. Ge0rG

    and it's missing clarification on which file elements are mandatory

  56. Zash

    Experimental doesn't need to be perfect

  57. daniel

    the idea isn’t to make it reslient against bumps but to better use it outside of jingle, no?

  58. Ge0rG

    Zash: me neither, but having smaller, reusable elements as their own XEPs looks like a good idea

  59. Zash

    I suppose

  60. dwd

    Ge0rG, "All child elements are OPTIONAL"

  61. dwd

    Ge0rG, Seems clear enough to me. :-)

  62. Ge0rG

    daniel: yes, but making it reusable will make it prone to bumping.

  63. jonas’

    I agree

  64. jonas’

    moving on

  65. Ge0rG

    dwd: indeed

  66. Zash

    I would appreciate a pointer to previous discussion

  67. jonas’

    4b) Proposed XMPP Extension: Stateless file sharing URL: https://xmpp.org/extensions/inbox/sfs.html Abstract: This specification describes a protocol for stateless asynchronous file sharing with integrity and transport flexibility. It allows clients to provide a good interoperable user experience in combination with Carbons and MAM.

  68. daniel

    +1

  69. dwd

    Zash, Yeah, same. Might have been in the XSF@ chatroom, but I'm sure I've seen something like this from larma before.

  70. dwd

    So this one is SIMS but based aorund the file metadata, so eradicates SIMS, right?

  71. Zash

    Eaiser to make a new XEP than to re-author SIMS?

  72. jonas’

    dwd, but based around the file-metadata and *not* around references

  73. Ge0rG

    wouldn't it be a much more sane approach to just let Marvin co-author SIMS and do all the fixes there?

  74. dwd

    Ge0rG, For this one in particular, I wondered about that approach myself.

  75. Zash

    +1. let them A/B fight for the throne of OOB

  76. jonas’

    the key difference would be "No mixed content, body is used for fallback only and not to transmit additional information." + "Not relying on underspecified usage of References (XEP-0372) [3]."

  77. daniel

    has there been a clear consensus on that we want this kind of refactor from SIMS?

  78. daniel

    because SIMS might still be useful for other things

  79. jonas’

    do we need consensus before accepting this as Experimental?

  80. Ge0rG

    jonas’: I like the first ones, and the last one is largely political

  81. jonas’

    ah, from that perspective

  82. dwd

    daniel, Hard to say, see my notes on communications elsewhere.

  83. jonas’

    Ge0rG, the first one and the last one are pretty much tied together

  84. jonas’

    I’m also +1 on this one, same as Zash

  85. Ge0rG

    So we are going to end up with clients sending three different "file attached" elements for compat reasons?

  86. dwd

    Ge0rG, Each supporting 19 different FT mechanisms?

  87. Ge0rG

    dwd: each supporting the same 19 mechanisms as the other one(s).

  88. Zash

    ... but in practice it's all equivalent to <body>https://foo/bar.png</>

  89. Zash

    Ge0rG, imagine the market for server-side translation modules!!!

  90. dwd

    Anyway, I'm +1 (in as much as I do not object)

  91. jonas’

    Ge0rG, currently, there is only OOB, right?

  92. jonas’

    so it would be at most two

  93. Ge0rG

    jonas’: there is SIMS

  94. dwd

    Ge0rG, I love your optimism that both clients would have any FT mechanisms in common at all.

  95. Ge0rG

    I'm on-list

  96. jonas’

    Ge0rG, not in any real-world use

  97. daniel

    and with the body fallback it's probably relatively safe to just drop oob at some point

  98. dwd

    daniel, I hate boyd fallback, but there we are...

  99. dwd

    daniel, I hate body fallback, but there we are...

  100. Zash

    But we have the body fallback indicator! It's just lacking a fallback...

  101. Zash

    So we have [+4, on-list]. Next?

  102. jonas’

    4c) Proposed XMPP Extension: Encryption for stateless file sharing URL: https://xmpp.org/extensions/inbox/esfs.html Abstract: This specification provides a protocol for sharing encrypted files using the stateless file sharing protocol (XEP-xxxx).

  103. jonas’

    +1, I sent feedback to the list

  104. daniel

    +1

  105. Zash

    +1

  106. jonas’

    (just now, so it’ll probably arrive tomorrow)

  107. jonas’

    (note that this directly depends on the previous one)

  108. daniel

    i'm not seeing that feedback

  109. daniel

    was this in reply to the proposed?

  110. jonas’

    daniel, as I said, I sent it just now, so it’ll take a while

  111. jonas’

    the list server hates me

  112. jonas’

    (peak delay for my mail was something like an hour or so.)

  113. daniel

    oh fair enough

  114. jonas’

    my feedback was mainly tha the cipher list should go in its own informational XEP like we have for hashes

  115. dwd

    Well, I think this has issues, but nothing insurmountable, so we'll publish first and fix afterward. I hope.

  116. jonas’

    dwd, is that a disguised +1?

  117. larma

    jonas’, agree, especially due to overlap with JET

  118. jonas’

    larma, excellent :)

  119. Ge0rG

    I like the Security Considerations.

  120. jonas’

    me too :D

  121. jonas’

    i chuckled when I reached that point

  122. Ge0rG

    +1

  123. jonas’

    Ge0rG, is that a vote?

  124. dwd

    jonas’, Yeah, +1. I was thinking mostly that it's unclear if every cipher suite will have or need a "key" and "IV" split like that. Most do, of course, but IIRC there are encrypted formats which essentially include the IV.

  125. Ge0rG

    jonas’: yes

  126. jonas’

    Ge0rG, you do realize that esfs depends strictly on sfs?

  127. jonas’

    and that you are on-list for sfs?

  128. Ge0rG

    jonas’: damn.

  129. Ge0rG

    I'm in a deadlock now

  130. jonas’

    think about that ;)

  131. Ge0rG

    if you can put <sources> inside of <encrypted> inside of <sources>, how many levels of encryption can you stack?

  132. dwd

    jonas’, As written, it does, but it could be "fixed" to be written around SIMS or something.

  133. jonas’

    Ge0rG, :D

  134. Ge0rG

    in that case I'm on-list.

  135. jonas’

    dwd, yes

  136. jonas’

    Ge0rG, thanks

  137. jonas’

    4d) Proposed XMPP Extension: Stickers URL: https://xmpp.org/extensions/inbox/stickers.html Abstract: This specification provides a protocol to send stickers and to create and share sticker packs.

  138. Ge0rG

    it doesn't duplicate SIMS functionality, so I'm less strict on that one.

  139. jonas’

    the hash calculation looks very familiar

  140. jonas’

    someone stole from '390 ;)

  141. Ge0rG

    on-list; I need to think about the technical implications as well as copyright violation issues.

  142. jonas’

    larma, since you’re around: please consider how to re-do it around NUL instead of ASCII separators, since ASCII separators are valid XML 1.1 (as opposed to 1.0), while NUL is not valid in any XML version.

  143. dwd

    I may be too old to fully understand what a Sticker is.

  144. jonas’

    yeah this one is more complex, I’m on-list too

  145. Ge0rG

    dwd: something like a large custom emoji

  146. dwd

    I mean, I'm *all* about the Giphy. But I'm not sure I understand Stickers. I'm going to on-list this one.

  147. dwd

    Ge0rG, Yeah, but they come in packs? Like wolves?

  148. jonas’

    Zash, daniel, ?

  149. daniel

    +1

  150. Zash

    +1

  151. daniel

    although I wonder if stickers might be better of with SIMS rather than file sharing

  152. Ge0rG

    dwd: that would be like different emoji fonts, or somesuch

  153. daniel doesn’t know how sticker work

  154. jonas’

    alright

  155. jonas’

    5) Pending Votes

  156. Ge0rG

    I'm +1 on #1001

  157. larma

    jonas’, I'd rather enforce that name,desc and summary may not include ascii seperators instead of using null byte (because whatever is in those should be displayable to end-users anyway), but I see your point.

  158. jonas’

    except for those started today, we have pending votes: - everyone except Ge0rG (thanks) on #1001 - dwd on advancement of CS-2020

  159. jonas’

    larma, let’s do that in addition, but being resilient against it comes at little cost

  160. Ge0rG

    jonas’: CS-2021?

  161. jonas’

    Ge0rG, yes

  162. dwd

    What's the current voting on CS-2021

  163. dwd

    ?

  164. jonas’

    dwd, everoyne +1, except you

  165. Ge0rG

    well, we *could* advance CS-2020 to Final, right?

  166. jonas’

    Ge0rG, no

  167. jonas’

    that needs a CFE which is at least 2w long

  168. jonas’

    so "we" cannot

  169. dwd

    Oh, I'll +0.

  170. jonas’

    thanks!

  171. Zash

    Maybe we could ask Board to add a special compliance suite thing in XEP-0001

  172. jonas’

    we’re already over our meeting time

  173. daniel

    also it needs to be 6 month old, no?

  174. jonas’

    please cast votes for #1001 on-list, please

  175. jonas’

    daniel, right, there was something about that ...

  176. jonas’

    6) Date of Next

  177. jonas’

    NOBODY KNOWS!!

  178. jonas’

    7) AOB

  179. jonas’

    anyone got any?

  180. Ge0rG

    CS-2020 is over a year old now!

  181. jonas’

    Ge0rG, OHH

  182. jonas’

    2020

  183. jonas’

    I always confuse those

  184. jonas’

    technically, it needs to have been in draft for 6m, but yes

  185. Ge0rG

    jonas’: I noticed ;)

  186. jonas’

    Ge0rG, that’s anyway next council’s problem

  187. Ge0rG

    > Update to Draft as per council vote on 2019/11/07.

  188. Ge0rG

    we could cast a CFE just now

  189. jonas’

    Ge0rG, I’m not sure how those work across council boundaries

  190. Ge0rG

    maybe it will yield useful input for CS-2021

  191. jonas’

    I know that LCs are implicitly restarted

  192. jonas’

    so we don’t win much

  193. dwd

    Ge0rG, "We" don't start CFEs anyway, that's purely an Editor action.

  194. jonas’

    that, too

  195. Ge0rG

    ignore everything I've said, it was just a sophisticated byrules troll attempt.

  196. Ge0rG

    *bylaws

  197. jonas’

    Ge0rG, ok, thanks for doing that while we’re already 4 minutes over.

  198. Ge0rG

    jonas’: I'm sorry.

  199. dwd

    Ge0rG, I think that's because whichever Council in Times Gone Past forgot that one.

  200. jonas’

    assuming no other AOB: Thank you all for this Council term. It was pleasure working with you. And special thanks (with cookies: 🍪) go to Tedd for consistently providing fun to read and comprehensive meeting minutes.

  201. dwd

    Ge0rG, Originally, I think neither Last Calls nor ProtoXEP Adoption/Publication were a Council thing, just Draft/Final advancements.

  202. jonas’

    8) Ite Meeting Est.

  203. dwd

    jonas’, Very much +1, and thanks for your excellent and concientious chairing.

  204. Ge0rG

    jonas’: thanks very much as well, it was great having you put structure into everything

  205. jonas’

    much of that was thanks to daves spreadsheet of doom

  206. Zash

    Thanks all. It's been a pleasure serving with you.

  207. jonas’

    oh and also the occasional email from Tedd with summaries of things which were forgotten about

  208. jonas’

    that person is incredibly valuable and we should find a way to send them covid-safe cookies or something.

  209. dwd

    Also, while obviously I hate to lose elections, at least if I lose this one I know I'll have been beaten by people who'll be good here.