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