XMPP Council - 2011-04-20

  1. stpeter has joined
  2. bear has left
  3. bear has joined
  4. stpeter has left
  5. Kanchil+ has joined
  6. Kanchil+ Kev: Done.
  7. Kev !agenda
  8. Kanchil+ Kev: 1) Roll call 2) Agenda bashing 3) Retract XEP-0192 4) Retract XEP-0193 5) Last Call on XEP-0262: Use of ZRTP in Jingle RTP Sessions 6) Vote on accepting version 1.1rc3 of XEP-0178: Best Practices for Use 7) Vote on accepting version 1.1rc1 of XEP-0171: Language Translation 8) Council concensus on removing Proposed from XEP-0001 9) Accept XEP-0220 version 0.6? 10) Accept XEP-0220 version 0.6? 11) Date of next meeting 12) Any other business Fini
  9. Kev Close enough.
  10. Vanaryon has joined
  11. Vanaryon has left
  12. stpeter has joined
  13. Kev wonders how many of the specs he'll have a chance to review before the meeting.
  14. fippo has joined
  15. MattJ has joined
  16. stpeter hi MattJ
  17. MattJ Hi
  18. stpeter I'm going to check 198 into git
  19. stpeter so that you can see the diff
  20. MattJ k
  21. MattJ thanks
  22. MattJ I'm confused about what is version 1.2 :)
  23. stpeter well
  24. stpeter 1.2 was confused in several respects
  25. stpeter but 1.2 is what's published on the website
  26. stpeter I cleaned up all the XEPs to refer to 6120/6121
  27. MattJ Ok, so 1.2rc2 is something else?
  28. stpeter I don't think we want council votes on all those reference updates
  29. MattJ No, we don't :)
  30. Kev I think we should probably have a Council item to say "Switch to 6120/6121 throughout".
  31. Kev No-one's going to object, but they are technically non-trivial changes to the dependencies of the XEPs.
  32. stpeter Kev: well, there *are* exceptions because in some of the specs we legitimately refer to 3920 or 3921
  33. stpeter e.g., to reference Nodeprep or whatever
  34. Kev Righty.
  35. stpeter those references have been retained
  36. stpeter but sure, a vote on that switch seems good
  37. linuxwolf has joined
  38. stpeter maybe we should make suite definitions while we're at it, although it's unclear to me if anyone ever used those
  39. Florob has joined
  40. bene has joined
  41. stpeter early agenda bashing ... I think that XEP-0178 is not quite ready for approval because fippo and I are still working out some fine points in the document on the standards@xmpp.org list
  42. Kev Right, I was going to suggest that.
  43. MattJ Ok, I'll stop reviewing it now then :)
  44. stpeter replies to fippo's latest email before the meeting begins
  45. stpeter I also have a conference call starting in 12 minutes (I'm now the IESG liaison to the IETF Tools Team, yay!), but I don't know how much attention that will take
  46. linuxwolf sounds like fun
  47. stpeter indeed
  48. Kev linuxwolf: it does? :)
  49. linuxwolf no, it does not (-:
  50. linuxwolf that was sarcasm
  51. stpeter linuxwolf: you'll be happy to hear that I also had a HYBI WG coordination call at 11 last night :)
  52. linuxwolf did it involve AES-CTR?
  53. linuxwolf (-:<
  54. stpeter no!
  55. linuxwolf good
  56. linuxwolf I noticed you actually posted something to the hybi list, too
  57. stpeter just using one of the reserved opcodes to signal if masking is enabled
  58. ralphm has joined
  59. stpeter hi ralph!
  60. linuxwolf /nod … but the oddest things become a hill to die on over there
  61. ralphm has left
  62. ralphm has joined
  63. ralphm hi
  64. MattJ Gah, phone... brb 2 minutes
  65. stpeter fippo: I've replied to you on the list
  66. Kev May as well get started, and let Matt catch up?
  67. Kev Or wait for him?
  68. linuxwolf I can catch up (-:
  69. linuxwolf trolls the vagueness
  70. stpeter :P
  71. Kev So
  72. Kev !agendaup
  73. Kanchil+ Kev: 1) Roll call
  74. linuxwolf presente
  75. ralphm here
  76. Kev MattJ's largely here.
  77. Kev I'm certainly here.
  78. Kev We're missing a Fritzy - I don't remember him saying he'd miss it, I should check I guess.
  79. Kev Will do so before the minutes.
  80. Kev !agendaup
  81. Kanchil+ Kev: 2) Agenda bashing
  82. Kev Anyone?
  83. linuxwolf has left
  84. linuxwolf has joined
  85. stpeter I bashed about 178
  86. Kev You did.
  87. stpeter before the meeting started
  88. Kev Onward, then.
  89. Kev !agendaup
  90. Kanchil+ Kev: 3) Retract XEP-0192
  91. MattJ Sorry, back
  92. stpeter we also talked about the 6120/6121 updates
  93. Kev Point.
  94. Kev !agendaappend 6120/6121 updates.
  95. Kanchil+ Kev: Done.
  96. stpeter thanks
  97. Kev So.
  98. stpeter nothing else here
  99. Kev !agendaup 0
  100. stpeter I might have an AOB or two
  101. Kanchil+ Kev: 3) Retract XEP-0192
  102. Kev +1
  103. MattJ +1
  104. linuxwolf +1
  105. ralphm this is kinda odd
  106. ralphm don't authors retract xeps?
  107. Kev Well, a Draft XEP can't actually be Retracted.
  108. Kev So we're really voting to Deprecate, I think.
  109. ralphm also, I don't think you can go from Draft to Retracted
  110. ralphm in that case +1
  111. Kev So, yes, let's make this a vote to deprecate and revote.
  112. Kev +1
  113. linuxwolf +1
  114. stpeter right, deprecate is correct
  115. stpeter http://xmpp.org/extensions/xep-0001.html#approval-std
  116. linuxwolf you beat me to the link
  117. Kev MattJ: Still +1?
  118. MattJ Still +1
  119. emcho has joined
  120. Kev !agendaup
  121. Kanchil+ Kev: 4) Retract XEP-0193
  122. Kev This is Deprecate too.
  123. Kev +1
  124. ralphm +1
  125. linuxwolf +1
  126. MattJ +1
  127. Kev !agendaup
  128. Kanchil+ Kev: 5) Last Call on XEP-0262: Use of ZRTP in Jingle RTP Sessions
  129. Kev I'm largely happy to Last Call anything :)
  130. linuxwolf (-:
  131. ralphm +1
  132. Kev +1
  133. linuxwolf +1
  134. stpeter it will make Phil Zimmerman happy, if nothing else
  135. MattJ +1
  136. Kev !agendaup
  137. Kanchil+ Kev: 6) Vote on accepting version 1.1rc3 of XEP-0178: Best Practices for Use
  138. Kev Skipping this one.
  139. stpeter nod
  140. Kev (Ongoing list discussion)
  141. Kev !agendaup
  142. Kanchil+ Kev: 7) Vote on accepting version 1.1rc1 of XEP-0171: Language Translation
  143. linuxwolf heh
  144. linuxwolf +1
  145. linuxwolf that was such a hard read (-:
  146. stpeter somehow that slipped through the cracks last year
  147. Kev This seems a bit of a strange thing to update. Given it'll break any existing implementations.
  148. stpeter right
  149. stpeter but as discussed on the list, there was agreement to fix it
  150. Kev Oh, I somehow missed that.
  151. linuxwolf right
  152. ralphm doesn't this require a numeral now?
  153. MattJ I guess I missed it too, but +1
  154. stpeter the '#' is now allowed in URNs
  155. stpeter s/now/not/
  156. ralphm I understand
  157. stpeter ralphm: this document was published before we had versioning
  158. ralphm but if it is being changed...
  159. linuxwolf hrm
  160. Kev The thread I can find on the lists is from last June, where Peter says "The authors ...approve of this change" but there was no discussion.
  161. stpeter Kev: because I poked them offlist
  162. stpeter AFAIK there was only ever the one implementation, but I'm happy to bring this back to the list
  163. stpeter with a versioning update to the namespace
  164. Kev I think "discussed on the list" is pushing it when there was only one person posting :p
  165. stpeter discussed among the authors
  166. Kev But if we believe there's only one implementation, I'm happy to change it.
  167. stpeter I can't promise that there's only one impl
  168. ralphm I really just asking whether it should be changed, not requiring it, per se.
  169. stpeter so let's take it to the list
  170. stpeter I'll start a thread about it right now
  171. linuxwolf /nod
  172. Kev I think just asking the list if anyone has implemented, and then voting in a fortnight or so seems safest.
  173. ralphm k
  174. Kev Even if there was only one implementation a year ago when you last posted, there *could* be more by now.
  175. Kev Everyone ok with that?
  176. MattJ Fine
  177. Kev !agendaup
  178. Kanchil+ Kev: 8) Council concensus on removing Proposed from XEP-0001
  179. linuxwolf wfm
  180. ralphm +1
  181. MattJ +1
  182. linuxwolf +1
  183. Kev Council isn't the approving body for XEP-0001, but it's good to be asked anyway :)
  184. ralphm Kev: you +1?
  185. Kev I'm not opposed to removing Proposed, but I note that this needs more thought than scrubbing it, so I'd quite like to know to what we're agreeing.
  186. Kev Specifically, if we remove Proposed, we no longer have a way to Reject a XEP.
  187. ralphm well, it just that we make XEP-0001 more in line with current practice
  188. MattJ This /was/ discussed on the list though :)
  189. Kev MattJ: Was there suggested text, though?
  190. MattJ Not that I recall without looking
  191. Kev I thought it only went as far as vaguely agreeing to get rid of Proposed.
  192. stpeter Kev: sure we do, it comes up for a vote while still in the Experimental state and the Council votes to Reject it
  193. Kev Which I'm fine with.
  194. ralphm I don't see a problem with moving the arrow from experimental to rejected
  195. Kev stpeter: I mean that the only valid state change to Rejected is from Proposed.
  196. Kev I'm entirely happy with allowing Council to Reject at any point in Experimental.
  197. Kev I think this would be preferable, in fact.
  198. ralphm I agree
  199. linuxwolf or we do what happens now, and never vote on the item (-:
  200. stpeter in general, a number of specs have ended up going from Proposed back to Experimental (Council feedback requires an updated version but the authors don't get around to that), and it's unclear when the XEP Editor is supposed to change it back from Proposed to Experimental
  201. Kev Right, the current problem is, as I understand it:
  202. stpeter seems cleaner to just get rid of Proposed
  203. Kev Author asks for vote to Draft on Experimental XEP. Council deem it not ready. As XEP-0001 stands, the XEP is then Rejected with no way to get it back.
  204. ralphm I don't think that the 'proposed' state adds much value
  205. Kev This is a fine problem to solve.
  206. linuxwolf let's dump it!
  207. Kev So if what we're discussing is removing Proposed from the state chart, and making the arrow go from Experimental to Rejected instead, and letting Council do this at any time (with appropriate majority vote), I'm happy with the proposal.
  208. linuxwolf that's what it sounds like to me
  209. ralphm I also note that there is no arrow from deferred back to experimental
  210. Kev Does anyone disagree with that assessment and/or have a different understanding?
  211. stpeter yes, that's the concrete proposal
  212. stpeter ralphm: also something to be fixed, then
  213. MattJ Kev, I don't
  214. Kev ralphm: Not in the diagram, but the text itself documents that this is permitted.
  215. Kev Ok, so we're good to move on then with Council support, excellent.
  216. Kev !agendaup
  217. Kanchil+ Kev: 9) Accept XEP-0220 version 0.6?
  218. ralphm in principle our 'experimental' is really 'proposed'
  219. Kev ralphm: Right.
  220. Kev I'm +1 on this.
  221. linuxwolf +1
  222. ralphm +1
  223. MattJ I'm going to vote on the lis
  224. MattJ t
  225. Kev MattJ: OK.
  226. MattJ I've been following the discussions, but haven't reviewed the latest diff (if it's changed)
  227. ralphm I can't think of any other XEP with so many implementations that is experimental
  228. stpeter posted to the list about 171
  229. MattJ ralphm, heh
  230. ralphm stpeter: thanks!
  231. stpeter always best to be careful :)
  232. linuxwolf hehe
  233. Kev !agendaup
  234. Kanchil+ Kev: 10) Accept XEP-0220 version 0.6?
  235. Kev !agendaup
  236. stpeter ralphm: it really should not have been Experimental when we copied it over from RFC 3920 to XEP-0220
  237. Kanchil+ Kev: 11) 6120/6121 updates.
  238. ralphm stpeter: right
  239. ralphm so, where are we wanting to move it to, really?
  240. Kev So, are we happy with Peter going through all the XEPs and replacing 3920 with 6120 and 3921 with 6121 where he deems appropriate?
  241. Kev +1
  242. ralphm +1
  243. stpeter ralphm: I think we need to move it to Draft before we can do anything else with it
  244. ralphm stpeter: agreed
  245. ralphm stpeter: and then last call it next week?
  246. ralphm :-)
  247. MattJ Kev, +1
  248. linuxwolf heh
  249. linuxwolf +1
  250. Kev !agendaup
  251. Kanchil+ Kev: 12) Date of next meeting
  252. Kev Next Wednesday, usual time? (1500GMT)
  253. linuxwolf wfm
  254. stpeter WFM
  255. ralphm I might not be available
  256. ralphm taking some time off
  257. MattJ +1
  258. stpeter I'll miss any meeting the following week (May 4) if we have one
  259. MattJ (to next week)
  260. ralphm (easter holidays)
  261. Kev ralphm: Happy to vote on-list?
  262. stpeter I'll be flying back from Amsterdam that day
  263. ralphm stpeter: you'll be here?
  264. stpeter ralphm: yes, on May 2-3 for the IESG retreat
  265. Florob has left
  266. ralphm stpeter: oh, nice. Are you only here on those days, or do you have more time?
  267. stpeter oh AOB?
  268. linuxwolf focus people!
  269. ralphm bang already
  270. stpeter hmph
  271. Kev stpeter: I'm waiting for Ralph to confirm he's happy to vote onlist.
  272. stpeter my other meeting was ending
  273. ralphm Kev: oh, I'm probably offline quite a bit
  274. Kev Ideally soon so we can get on with AOB before 30minute tolerance.
  275. stpeter I received a submission that sounds just like the April 1 XEP :) http://xmpp.org/extensions/inbox/json.html
  276. Kev ralphm: I'll take that as a "Yes" :)
  277. ralphm Kev: but I have 2 weeks, so sure
  278. stpeter however, it is legitimate
  279. Kev !agendaup
  280. Kanchil+ Kev: 13) Any other business
  281. stpeter I'll send a notice to the list after I clean it up a bit
  282. stpeter didn't want to announce it right before this meeting
  283. emcho are outsiders allowed to speak?
  284. stpeter it's nostly BOSH-ish
  285. stpeter s/n/m/
  286. Kev emcho: I don't see why not.
  287. emcho concerning the any other business item
  288. emcho last thursday stpeter mentioned on the jingle list that "The XMPP Council will decide at its next meeting whether to accept [Coin] as an official XEP". Peter, is this the meeting you were referring to?
  289. Kev emcho: It wasn't added to the agenda.
  290. Kev emcho: I'll make sure it's on next week's.
  291. emcho Kev: k thanks!
  292. ralphm stpeter: oh wow, that's classic. I'm not quite sure what to think about this JSON-encoded-XMPP-for-the-sake-of-BOSH
  293. linuxwolf /sigh
  294. Kev So, I think there's nothing to do with this protoXEP, it's just a proposal and soon we'll be voting on it, right?
  295. ralphm let's publish it
  296. ralphm +1
  297. ralphm if it comes up for vote
  298. Kev I'm impressed that it seems to take my ugly proposal from the April 1st XEP and make it less legible :D
  299. MattJ Kev, +1 :(
  300. ralphm they can battle!
  301. Kev Anyway.
  302. Kev AOAOB?
  303. linuxwolf ugh
  304. linuxwolf none from me
  305. MattJ None
  306. ralphm nope
  307. Kev Excellent.
  308. Kev Thanks all!
  309. ralphm hooray!
  310. Kev bangs the gavel.
  311. linuxwolf waves
  312. Kev 32 minutes :(
  313. linuxwolf has left
  314. stpeter Kev: check the date on that submission, though
  315. stpeter it predates yours, but there was some IPR wrangling at Nokia
  316. ralphm woah
  317. Kev stpeter: Oh. I wonder why I didn't remember this, then.
  318. stpeter Kev: because I never announced it until now
  319. Kev Excellent.
  320. stpeter this got lost in my inbox
  321. stpeter along with many other old topics
  322. stpeter works to get his inbox back down from 5 to 0 :)
  323. stpeter emcho: sorry about the snafu, we'll get it on next week's agenda
  324. fippo stpeter: +1 @ 0178
  325. stpeter fippo: excellent, thanks
  326. emcho stpeter: no problem at all
  327. MattJ emcho, since discussions are currently happening on the list about Coin, it's probably wise to wait a week anyway
  328. ralphm I am not quite sure about JSON and extensibility in general
  329. emcho MattJ: yes that makes sense
  330. stpeter ralphm: me neither
  331. MattJ ralphm, I'm not sure I'm happy with this XEP :/
  332. ralphm What I am seeing happening at, for example, the activity streams stuff saddens me
  333. stpeter MattJ: true
  334. Kev ralphm: JSON isn't any less extensible than XML, you just need to make it horribly ugly to achieve the same things.
  335. stpeter :)
  336. MattJ It's a non-standard translation from XML to JSON
  337. MattJ Prosody could easily support JSON in BOSH (wait, it does since 1st April...)
  338. Kev :)
  339. ralphm Kev: that's my point. This is how it goes: 1) XML SUCKS! Let's use JSON, because it is *easier*
  340. MattJ But if we were to do it in the style of this XEP, we would use JSON that matches our internal stanza structures
  341. ralphm 2) hmm, we need to change how many values this attribute can have, let's up the version
  342. ralphm 3) hmm, we really need extensibility. Let's add namespaces.
  343. MattJ Otherwise we'd end up doing all kinds of transformations on the server that I'm sure would negate any performance advantages on the client
  344. ralphm 4) WOW. This is HORRIBLE!
  345. ralphm 5) Let's use XML?
  346. Kev Supporting this protoXEP seems to make the server work much harder.
  347. Kev ralphm: I think there are plenty of cases where JSON is a reasonable format, to be fair.
  348. stpeter ralphm: :)
  349. ralphm Kev: yes, but I don't think it quite works for an exchange standard between services
  350. Kev Right.
  351. Kev It works well when it's an internal transfer format.
  352. Kev e.g. Ajaxy things.
  353. stpeter right
  354. stpeter Kev: but internal is the new external
  355. Kev Please let's not get started with that silliness here.
  356. ralphm Well, it is used for APIs quite a bit too
  357. stpeter looks like I need to update http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/
  358. stpeter ralphm: it seems you were DNV on XEP 65
  359. ralphm and as long as those namespaces are controlled by one entity for a particular service, that's probably ok
  360. ralphm stpeter: noo?
  361. bene has left
  362. ralphm stpeter: that's sad. I am +1 on the changes. Didn't I pass this on?
  363. Kev NAFAIK.
  364. ralphm Let me get my time machine then.
  365. ralphm cya
  366. ralphm has left
  367. stpeter I might have missed it
  368. stpeter (sorry, was replying to email and processing XEPs so I missed ralphm)
  369. stpeter updates the voting table and takes appropriate XEP Editor actions
  370. stpeter scrolls up to determine action items
  371. emcho has left
  372. stpeter another action item for next week is http://xmpp.org/extensions/inbox/sensors.html (it's been updated to reflect earlier feedback)
  373. Kev Have they asked for another vote, then?
  374. stpeter they asked me if it could be reconsidered given that they'd updated it, yes
  375. Kev Ok.
  376. stpeter Kev: how are we handling new XEP authors now w.r.t. git check-ins?
  377. fippo stpeter: no action about 220 yet please - it seems some examples (13) are buggy and I still need to read the latest version
  378. stpeter fippo: right -- we're waiting for a vote from Nathan Fritz as well
  379. stpeter ack
  380. stpeter reads http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110420/ instead of continually scrolling up
  381. Kev stpeter: We use the Gitosis stuff to give them access, I guess.
  382. Kev Or just ask them to fork us on Gitorious and you can do stuff that way.
  383. stpeter the latter seems easier :)
  384. stpeter http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/ updated
  385. Kev Thanks.
  386. MattJ > "My apologies for the error, naturally that is 2011-05-10."
  387. MattJ stpeter, I signed the date on a bank form the other day as "2009", you're forgiven :)
  388. stpeter haha
  389. stpeter at least I have the decade correct
  390. stpeter corrects an error in http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/ (MW to vote on list about the dialback spec)
  391. fippo has left
  392. Tobias has joined
  393. Tobias has left
  394. Tobias has joined
  395. Tobias has left
  396. Tobias has joined
  397. Tobias has left
  398. Tobias has joined
  399. stpeter has left
  400. Tobias has left