XMPP Council - 2012-04-18

  1. stpeter has joined
  2. stpeter has left
  3. fippo has joined
  4. Tobias has joined
  5. Neustradamus has left
  6. Neustradamus has joined
  7. Tobias has left
  8. Tobias has joined
  9. Neustradamus has left
  10. Neustradamus has joined
  11. Kev has left
  12. Kev has joined
  13. Zash has joined
  14. linuxwolf has joined
  15. stpeter has joined
  16. ralphm has joined
  17. ralphm waves
  18. stpeter :)
  19. Tobias howdy
  20. Kev Hi Ralph.
  21. Kev Can we just vote on http://matthewwild.co.uk/uploads/message-archive-management.html regardless of Matt not submitting it yet?
  22. Kev He posted to the list some time ago that we could consider that his submission if he didn't get around to it...and he hasn't.
  23. stpeter lazy bastard
  24. ralphm are we force-fed specs now
  25. ralphm ?
  26. stpeter heh
  27. linuxwolf Kev: take authorship … I think I remember MattJ offering that to you at one point (-:
  28. MattJ has joined
  29. stpeter speak of the devil!
  30. MattJ I'm in a conf meeting that looks like it might overrun
  31. ralphm hi devel^WMattJ
  32. ralphm hm
  33. ralphm oh well
  34. MattJ I'll try and pull myself out in a few
  35. linuxwolf ugh
  36. Kev ralphm / Tobias / linuxwolf: Do you guys mind waiting 5mins then to see if MattJ can escape?
  37. Tobias nope..i don't mind
  38. linuxwolf uh
  39. linuxwolf I guess not ...
  40. MattJ Thanks
  41. ralphm Kev: do you think we have to wait like for the MAM spec?
  42. linuxwolf I have a hard stop at 9:30
  43. linuxwolf MDT
  44. linuxwolf 15:30 UTC?
  45. Kev That's 30mins from now.
  46. stpeter right
  47. linuxwolf exactly
  48. stpeter Matt is Meeting Man!
  49. linuxwolf heh
  50. ralphm that's a great time to stop anyway
  51. stpeter well, Meeting Man™
  52. linuxwolf today is my light day
  53. ralphm we shouldn't need the full time
  54. stpeter works to get his inbox below 50 messages
  55. linuxwolf is ticked off at the removal of "javascript:" bookmark url support
  56. stpeter really?
  57. stpeter that's wrong
  58. linuxwolf yeah
  59. linuxwolf it's a Security Exploit
  60. linuxwolf apparently
  61. Kev That's a little irritating.
  62. linuxwolf it's why I bounce between Chrome and FF at this point
  63. linuxwolf if I could type "http://xmpp.org/extensions/xep45" and have it "do the right thing", I would be happy (-:
  64. MattJ Ok, let's go
  65. linuxwolf well, not irritated
  66. Kev 1) Roll call.
  67. Kev I'm here.
  68. linuxwolf presete
  69. linuxwolf gah
  70. ralphm here
  71. MattJ Here
  72. Kev Tobias: Ping!
  73. ralphm linuxworf: what about smart bookmarks? I usually just type xep 0045
  74. Tobias pong
  75. linuxwolf I don't want to type the "45" 9-:
  76. linuxwolf I suggest we start with MAM first
  77. MattJ Heh
  78. linuxwolf that's Message Archiving Manager, not Matthew A. Miller (-:
  79. Kev linuxwolf: Really? OK, I don't mind.
  80. MattJ linuxwolf, Oh, so we have PSA and MAM?
  81. Kev 2) MAM http://matthewwild.co.uk/uploads/message-archive-management.html Accept as XEP?
  82. linuxwolf +1
  83. MattJ +1
  84. Tobias +1
  85. ralphm !
  86. ralphm +1
  87. Kev And MattJ will, on pain of DEATH send the XML to Peter today.
  88. MattJ +1
  89. Kev +1.
  90. ralphm +1
  91. linuxwolf +1
  92. Tobias +1
  93. Kev 3) Dialback: * Where does this live? * How far does it go?
  94. MattJ The XSF's powers are getting scary
  95. stpeter yow
  96. ralphm whose death, by the way?
  97. Kev ralphm: NaN
  98. stpeter first we had POKE, now we'll have SMITE?
  99. Kev linuxwolf: This was yours, I think?
  100. linuxwolf I suggested it ...
  101. linuxwolf as the work on DNA slowly progresses, we need to have a dialback progressed to a "recommend implement" state, with fixes
  102. linuxwolf now, I'll defer to stpeter (-:
  103. stpeter heh
  104. stpeter ok, I chatted with fippo in Paris at the IETF meeting and we agreed that it would be best to document dialback at the IETF (again) so that we can put all these federation + DNA pieces together in the same place
  105. ralphm that seems sensible
  106. MattJ Hmm, ok
  107. Kev stpeter: So is this the authors saying they want to retract the XEP?
  108. stpeter basically, it appears that for DNA purposes we'll be using dialback as a "transport" for various credentials (dbkeys) and assertions (DANE, /.well-known/, etc.)
  109. fippo kev: not yet i think -- actually i have a version with minor bugfixes and a nice new feature
  110. Kev fippo: Ah, you're here :)
  111. Kev So is all we need to do to wait for fippo and stpeter to agree on a new version an submit it?
  112. Kev And then to move it up to Draft?
  113. MattJ To the XSF or IETF?
  114. stpeter yes, fippo and I need to chat further, but I wanted to socialize the idea of moving this back to the IETF
  115. Kev MattJ: I just understood from fippo that he'd like to get the XEP in order first.
  116. Kev Which seems to make sense to me, we can always then deprecate that once it's RFCd.
  117. stpeter possible, yes
  118. ralphm ok, but that case the venue is the XSF, not the IETF
  119. stpeter truly I'd prefer to just get to work on it at the IETF
  120. linuxwolf I just want *something* to progress
  121. fippo doesn't care much where that happens
  122. stpeter linuxwolf: :)
  123. Kev I have, I *think*, no objection to moving this back to the IETF, although I also aren't sure there's a great benefit to it.
  124. ralphm stpeter: have any of the interested parties expressed a preference?
  125. Zash Dialback in SMTP?
  126. linuxwolf the perceived benefit is that all federation basics are by one SDO
  127. stpeter Zash: um, no :)
  128. linuxwolf "basics" being a relative term
  129. Kev So, there's no Council action here anyway, right?
  130. Tobias right...if it catches one it could be made a requirement of xmpp-core-bis
  131. stpeter Kev: no Council action needed at this time, I think
  132. Kev OK.
  133. linuxwolf Tobias: we're thinking this is either stand-alone, or part of the federation/dna draft
  134. Kev 4) Obsoleting XEP-0130 No objections received onlists.
  135. Kev So I'm ok with this.
  136. ralphm +1
  137. linuxwolf +1
  138. linuxwolf well
  139. linuxwolf maybe move it to deprecated
  140. stpeter sure, Deprecated is fine with me
  141. Tobias linuxwolf, right..but if integrated in dna, dna could be made a requirement
  142. linuxwolf dot the i's and cross the t's
  143. Kev linuxwolf: +1
  144. Tobias +1 on obsoleting
  145. Kev Tobias: But not deprecating?
  146. MattJ Same here
  147. MattJ er
  148. stpeter yeah, deprecate is fine -- that just means the Council will need to look at the issue again in 6+ months :)
  149. MattJ Sorry, I was scrolled up
  150. linuxwolf Tobias: DNA would be a requirement, if one supports this not-yet-draft thing
  151. ralphm Why in two steps?
  152. Tobias stpeter, and obsoleting would move it off any future agenda?
  153. Kev ralphm: I think we're supposed to do it in two steps, without checking XEP-0001.
  154. linuxwolf ralphm: according to XEP-0001, it's supposed to be a 2-step process
  155. stpeter right
  156. ralphm can we vote on it being automatically moved to obsolete in 6 months?
  157. linuxwolf sounds good to me
  158. linuxwolf +1
  159. Tobias +1
  160. Kev ralphm: I don't think it's going to be a hardship to vote on this again in 6 months :)
  161. linuxwolf w00t … a use for <councilnote/> (-:
  162. stpeter haha
  163. Kev But sure, let's do that.
  164. stpeter speaking of which
  165. ralphm +1
  166. Kev OK.
  167. Kev stpeter: I've seen no objections, so please integrate :)
  168. linuxwolf <councilnote>Within six months, this XEP will automatically be determined to be Obsolete</councilnote>
  169. Kev 5) Date of next meeting.
  170. ralphm SBTSBC
  171. linuxwolf SBtSBC works for me
  172. MattJ Same wfm
  173. Tobias wfm
  174. Kev It works for me next week (mostly) it won't the week after. So you may need to think whether you want to meet without me in a fortnight :)
  175. Kev 6) AOB?
  176. linuxwolf 05/02 will not work for me
  177. linuxwolf head's up
  178. stpeter I will be on an airplane on May 2
  179. linuxwolf I say we skip 05/02 (-:
  180. linuxwolf and, no AOB from me
  181. stpeter AOB: http://mail.jabber.org/pipermail/council/2012-April/003459.html
  182. linuxwolf (other AOB?)
  183. stpeter Kev and Matt said it looked fine
  184. linuxwolf this Matt
  185. stpeter if others have feedback, please say so here
  186. stpeter linuxwolf: of course, the other one is Matthew :)
  187. ralphm isn't MUST too strong?
  188. MattJ Missed that email somehow
  189. ralphm it's not like stuff actually breaks, apart from security
  190. MattJ Oh, it's 2h old
  191. linuxwolf (-:
  192. stpeter MattJ: right
  193. stpeter we can discuss next time
  194. stpeter or on the list
  195. stpeter or more widely
  196. MattJ Sure
  197. stpeter no big hurry
  198. Kev Shall we continue this onlist, then?
  199. linuxwolf It seems ok to me, since ZRTP hashes will be different, unless you did something horribly wrong (IIRC)
  200. stpeter ralphm: Phil Zimmermann said must so that seemed good enough for me ;-)
  201. ralphm :-)
  202. ralphm I'm ok with this change
  203. Kev Any other any other business?
  204. stpeter but yeah, listage is fine with me
  205. stpeter no other AOBs here
  206. Kev Right, I think we're done with 4 mins to spare then.
  207. Kev Thanks all.
  208. linuxwolf /whew
  209. Kev bangs the gavel.
  210. Tobias thanks
  211. linuxwolf grazie
  212. MattJ Merci
  213. stpeter applies the councilnote patch
  214. Kev stpeter: Please remember to extract the XML from Matt or let him die trying :)
  215. MattJ :)
  216. MattJ I'm going to work on it right now
  217. linuxwolf I suppose we could launch some root attacks against his computers...
  218. stpeter heehee
  219. linuxwolf joking!
  220. stpeter ralphm: I think s/MUST/needs to be/ is fine in that note -- it is just a note, after all
  221. Zash linuxwolf: http://xep.xmpp.zash.se/muc (re earlier talk)
  222. linuxwolf you should all read < http://www.circleid.com/posts/dns_resolution_browsers_hope_for_the_future/ >, then start discussing
  223. linuxwolf Zash: nice
  224. ralphm stpeter: nod
  225. stpeter linuxwolf: thanks for the reminder
  226. stpeter reads
  227. stpeter I mean, I had dinner with Andrew and a few other folks in Paris, but that was on a slightly different topic
  228. linuxwolf (-:
  229. linuxwolf it was the third most talked about topic for me in Paris
  230. linuxwolf and I really think everyone should care
  231. stpeter yep
  232. stpeter linuxwolf: he and I were talking about ways to get beyond the public suffix list (which is kind of like /etc/hosts for Web 2.0 or somesuch)
  233. ralphm linuxwolf: interesting. Twisted implements its own resolver, partly because system calls are blocking
  234. linuxwolf ralphm: exactly
  235. linuxwolf "everyone" ends up doing their own, which all behave slightly differently, and give some us headaches
  236. Zash and prosody ...
  237. ralphm I also found out recently that Twisted's SRV connector is hasn't changed much in 9 years, but doesn't work as specified in the SRV RFC
  238. linuxwolf but I can tell you that "DNS people" don't see the current state of things as a problem, necessarily
  239. stpeter interesting, http://xmpp.org/extensions/xep-0086.html is deprecated, too (as is XEP-0093)
  240. stpeter I wonder if it's time to change 86 to Obsolete
  241. linuxwolf the amount of time spent talking past each other is a little astounding
  242. ralphm another trend is that recent versions of Ubuntu ship with dnsmasq by default
  243. linuxwolf can you tell my 15:30 meeting ended five minutes ago (-:
  244. stpeter quick meeting!
  245. linuxwolf daily scrum!
  246. ralphm linuxwolf: i.e. enabled by default
  247. Zash ralphm: I've installed a local resolver on all my boxes
  248. ralphm linuxwolf: with network-manager telling it the nameservers it should forward requests, too
  249. ralphm to
  250. linuxwolf ralphm: that's fine and good, but if my code can't get there in an efficient manner, I might as well only use /etc/hosts
  251. linuxwolf the problem is not the resolver or nameservers, it's the libraries
  252. linuxwolf or the system calls
  253. ralphm I understand this
  254. linuxwolf (and the system calls?)
  255. linuxwolf sorry, this is a rage subject for me now (-:
  256. ralphm but this is an interesting approach as this gives it a better API than system calls: the DNS protocol
  257. linuxwolf dude, doing the DNS protocol properly is **HARD**
  258. stpeter regarding XEP-0130, I think we just assign it an expiration date, see http://xmpp.org/extensions/xep-0001.html#expiration
  259. ralphm better is subjective, of course
  260. ralphm richer is probably a better word
  261. linuxwolf I'd rather not have to think about YAP if I don't have to
  262. ralphm agreed
  263. linuxwolf I'd rather have a function or two I can call, and "magic" happens
  264. ralphm but not blocking
  265. linuxwolf also, lack of an API makes processing DNSSEC very very difficult
  266. linuxwolf well, lack of a library
  267. fippo linuxwolf: unbound
  268. linuxwolf then we might want to tack DANE on top of all that, and properly validate chains
  269. linuxwolf fippo: it lauches a new process, which means I can't use it everywhere I want to
  270. linuxwolf I've told them about it, too
  271. linuxwolf each request forks a new process to make the DNS request
  272. linuxwolf that is almost worse than blocking function calls in a lot of environments
  273. fippo linuxwolf: iirc it can use just a single background thread which runs an event loop
  274. Zash libunbound \o/
  275. linuxwolf fippo: it can, but I've found it difficult to get setup that way
  276. fippo (but doesn't give any means of integrating that loop into your own eventloop)
  277. linuxwolf and it's still spawning a new process
  278. linuxwolf it's eating up far more resources than just handling it async would
  279. linuxwolf less on Linux than Darwin or Mac
  280. linuxwolf er
  281. linuxwolf Darwin or Windows
  282. linuxwolf and using it on Android or iOS is …. troubleshome
  283. Kev Tobias has libunbound working on Android, I believe.
  284. linuxwolf I tried to get it to work for iOS and had issues
  285. linuxwolf at one point, I couldn't get it to compile in NDK, but that was a *long* time ago
  286. linuxwolf and, anyway, spawning a process (or a thread) to make something async is a resource-hogging cop-out
  287. linuxwolf "all" of the platforms (most of us care about) have a way to manage asynchronous I/O is a very efficient manner
  288. linuxwolf takes a breath, and directs this ire back at the folks who it should actually be directed at (-:
  289. Tobias has joined
  290. fippo has left
  291. Zash has left
  292. Neustradamus has left
  293. Neustradamus has joined
  294. Neustradamus has left
  295. Neustradamus has joined
  296. Neustradamus has left
  297. Neustradamus has joined
  298. Tobias has left
  299. Tobias has joined
  300. stpeter has left
  301. stpeter has joined
  302. ralphm has left
  303. stpeter has left
  304. Tobias has left
  305. Neustradamus has joined
  306. linuxwolf has left
  307. Neustradamus has joined
  308. Neustradamus has left
  309. Neustradamus has joined