XMPP Council - 2012-04-18


  1. ralphm waves

  2. stpeter

    :)

  3. Tobias

    howdy

  4. Kev

    Hi Ralph.

  5. Kev

    Can we just vote on http://matthewwild.co.uk/uploads/message-archive-management.html regardless of Matt not submitting it yet?

  6. 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.

  7. stpeter

    lazy bastard

  8. ralphm

    are we force-fed specs now

  9. ralphm

    ?

  10. stpeter

    heh

  11. linuxwolf

    Kev: take authorship … I think I remember MattJ offering that to you at one point (-:

  12. stpeter

    speak of the devil!

  13. MattJ

    I'm in a conf meeting that looks like it might overrun

  14. ralphm

    hi devel^WMattJ

  15. ralphm

    hm

  16. ralphm

    oh well

  17. MattJ

    I'll try and pull myself out in a few

  18. linuxwolf

    ugh

  19. Kev

    ralphm / Tobias / linuxwolf: Do you guys mind waiting 5mins then to see if MattJ can escape?

  20. Tobias

    nope..i don't mind

  21. linuxwolf

    uh

  22. linuxwolf

    I guess not ...

  23. MattJ

    Thanks

  24. ralphm

    Kev: do you think we have to wait like for the MAM spec?

  25. linuxwolf

    I have a hard stop at 9:30

  26. linuxwolf

    MDT

  27. linuxwolf

    15:30 UTC?

  28. Kev

    That's 30mins from now.

  29. stpeter

    right

  30. linuxwolf

    exactly

  31. stpeter

    Matt is Meeting Man!

  32. linuxwolf

    heh

  33. ralphm

    that's a great time to stop anyway

  34. stpeter

    well, Meeting Man™

  35. linuxwolf

    today is my light day

  36. ralphm

    we shouldn't need the full time

  37. stpeter works to get his inbox below 50 messages

  38. linuxwolf is ticked off at the removal of "javascript:" bookmark url support

  39. stpeter

    really?

  40. stpeter

    that's wrong

  41. linuxwolf

    yeah

  42. linuxwolf

    it's a Security Exploit

  43. linuxwolf

    apparently

  44. Kev

    That's a little irritating.

  45. linuxwolf

    it's why I bounce between Chrome and FF at this point

  46. linuxwolf

    if I could type "http://xmpp.org/extensions/xep45" and have it "do the right thing", I would be happy (-:

  47. MattJ

    Ok, let's go

  48. linuxwolf

    well, not irritated

  49. Kev

    1) Roll call.

  50. Kev

    I'm here.

  51. linuxwolf

    presete

  52. linuxwolf

    gah

  53. ralphm

    here

  54. MattJ

    Here

  55. Kev

    Tobias: Ping!

  56. ralphm

    linuxworf: what about smart bookmarks? I usually just type xep 0045

  57. Tobias

    pong

  58. linuxwolf

    I don't want to type the "45" 9-:

  59. linuxwolf

    I suggest we start with MAM first

  60. MattJ

    Heh

  61. linuxwolf

    that's Message Archiving Manager, not Matthew A. Miller (-:

  62. Kev

    linuxwolf: Really? OK, I don't mind.

  63. MattJ

    linuxwolf, Oh, so we have PSA and MAM?

  64. Kev

    2) MAM http://matthewwild.co.uk/uploads/message-archive-management.html Accept as XEP?

  65. linuxwolf

    +1

  66. MattJ

    +1

  67. Tobias

    +1

  68. ralphm

    !

  69. ralphm

    +1

  70. Kev

    And MattJ will, on pain of DEATH send the XML to Peter today.

  71. MattJ

    +1

  72. Kev

    +1.

  73. ralphm

    +1

  74. linuxwolf

    +1

  75. Tobias

    +1

  76. Kev

    3) Dialback: * Where does this live? * How far does it go?

  77. MattJ

    The XSF's powers are getting scary

  78. stpeter

    yow

  79. ralphm

    whose death, by the way?

  80. Kev

    ralphm: NaN

  81. stpeter

    first we had POKE, now we'll have SMITE?

  82. Kev

    linuxwolf: This was yours, I think?

  83. linuxwolf

    I suggested it ...

  84. linuxwolf

    as the work on DNA slowly progresses, we need to have a dialback progressed to a "recommend implement" state, with fixes

  85. linuxwolf

    now, I'll defer to stpeter (-:

  86. stpeter

    heh

  87. 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

  88. ralphm

    that seems sensible

  89. MattJ

    Hmm, ok

  90. Kev

    stpeter: So is this the authors saying they want to retract the XEP?

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

  92. fippo

    kev: not yet i think -- actually i have a version with minor bugfixes and a nice new feature

  93. Kev

    fippo: Ah, you're here :)

  94. Kev

    So is all we need to do to wait for fippo and stpeter to agree on a new version an submit it?

  95. Kev

    And then to move it up to Draft?

  96. MattJ

    To the XSF or IETF?

  97. stpeter

    yes, fippo and I need to chat further, but I wanted to socialize the idea of moving this back to the IETF

  98. Kev

    MattJ: I just understood from fippo that he'd like to get the XEP in order first.

  99. Kev

    Which seems to make sense to me, we can always then deprecate that once it's RFCd.

  100. stpeter

    possible, yes

  101. ralphm

    ok, but that case the venue is the XSF, not the IETF

  102. stpeter

    truly I'd prefer to just get to work on it at the IETF

  103. linuxwolf

    I just want *something* to progress

  104. fippo doesn't care much where that happens

  105. stpeter

    linuxwolf: :)

  106. 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.

  107. ralphm

    stpeter: have any of the interested parties expressed a preference?

  108. Zash

    Dialback in SMTP?

  109. linuxwolf

    the perceived benefit is that all federation basics are by one SDO

  110. stpeter

    Zash: um, no :)

  111. linuxwolf

    "basics" being a relative term

  112. Kev

    So, there's no Council action here anyway, right?

  113. Tobias

    right...if it catches one it could be made a requirement of xmpp-core-bis

  114. stpeter

    Kev: no Council action needed at this time, I think

  115. Kev

    OK.

  116. linuxwolf

    Tobias: we're thinking this is either stand-alone, or part of the federation/dna draft

  117. Kev

    4) Obsoleting XEP-0130 No objections received onlists.

  118. Kev

    So I'm ok with this.

  119. ralphm

    +1

  120. linuxwolf

    +1

  121. linuxwolf

    well

  122. linuxwolf

    maybe move it to deprecated

  123. stpeter

    sure, Deprecated is fine with me

  124. Tobias

    linuxwolf, right..but if integrated in dna, dna could be made a requirement

  125. linuxwolf

    dot the i's and cross the t's

  126. Kev

    linuxwolf: +1

  127. Tobias

    +1 on obsoleting

  128. Kev

    Tobias: But not deprecating?

  129. MattJ

    Same here

  130. MattJ

    er

  131. stpeter

    yeah, deprecate is fine -- that just means the Council will need to look at the issue again in 6+ months :)

  132. MattJ

    Sorry, I was scrolled up

  133. linuxwolf

    Tobias: DNA would be a requirement, if one supports this not-yet-draft thing

  134. ralphm

    Why in two steps?

  135. Tobias

    stpeter, and obsoleting would move it off any future agenda?

  136. Kev

    ralphm: I think we're supposed to do it in two steps, without checking XEP-0001.

  137. linuxwolf

    ralphm: according to XEP-0001, it's supposed to be a 2-step process

  138. stpeter

    right

  139. ralphm

    can we vote on it being automatically moved to obsolete in 6 months?

  140. linuxwolf

    sounds good to me

  141. linuxwolf

    +1

  142. Tobias

    +1

  143. Kev

    ralphm: I don't think it's going to be a hardship to vote on this again in 6 months :)

  144. linuxwolf

    w00t … a use for <councilnote/> (-:

  145. stpeter

    haha

  146. Kev

    But sure, let's do that.

  147. stpeter

    speaking of which

  148. ralphm

    +1

  149. Kev

    OK.

  150. Kev

    stpeter: I've seen no objections, so please integrate :)

  151. linuxwolf

    <councilnote>Within six months, this XEP will automatically be determined to be Obsolete</councilnote>

  152. Kev

    5) Date of next meeting.

  153. ralphm

    SBTSBC

  154. linuxwolf

    SBtSBC works for me

  155. MattJ

    Same wfm

  156. Tobias

    wfm

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

  158. Kev

    6) AOB?

  159. linuxwolf

    05/02 will not work for me

  160. linuxwolf

    head's up

  161. stpeter

    I will be on an airplane on May 2

  162. linuxwolf

    I say we skip 05/02 (-:

  163. linuxwolf

    and, no AOB from me

  164. stpeter

    AOB: http://mail.jabber.org/pipermail/council/2012-April/003459.html

  165. linuxwolf

    (other AOB?)

  166. stpeter

    Kev and Matt said it looked fine

  167. linuxwolf

    this Matt

  168. stpeter

    if others have feedback, please say so here

  169. stpeter

    linuxwolf: of course, the other one is Matthew :)

  170. ralphm

    isn't MUST too strong?

  171. MattJ

    Missed that email somehow

  172. ralphm

    it's not like stuff actually breaks, apart from security

  173. MattJ

    Oh, it's 2h old

  174. linuxwolf

    (-:

  175. stpeter

    MattJ: right

  176. stpeter

    we can discuss next time

  177. stpeter

    or on the list

  178. stpeter

    or more widely

  179. MattJ

    Sure

  180. stpeter

    no big hurry

  181. Kev

    Shall we continue this onlist, then?

  182. linuxwolf

    It seems ok to me, since ZRTP hashes will be different, unless you did something horribly wrong (IIRC)

  183. stpeter

    ralphm: Phil Zimmermann said must so that seemed good enough for me ;-)

  184. ralphm

    :-)

  185. ralphm

    I'm ok with this change

  186. Kev

    Any other any other business?

  187. stpeter

    but yeah, listage is fine with me

  188. stpeter

    no other AOBs here

  189. Kev

    Right, I think we're done with 4 mins to spare then.

  190. Kev

    Thanks all.

  191. linuxwolf

    /whew

  192. Kev bangs the gavel.

  193. Tobias

    thanks

  194. linuxwolf

    grazie

  195. MattJ

    Merci

  196. stpeter applies the councilnote patch

  197. Kev

    stpeter: Please remember to extract the XML from Matt or let him die trying :)

  198. MattJ

    :)

  199. MattJ

    I'm going to work on it right now

  200. linuxwolf

    I suppose we could launch some root attacks against his computers...

  201. stpeter

    heehee

  202. linuxwolf

    joking!

  203. stpeter

    ralphm: I think s/MUST/needs to be/ is fine in that note -- it is just a note, after all

  204. Zash

    linuxwolf: http://xep.xmpp.zash.se/muc (re earlier talk)

  205. linuxwolf

    you should all read < http://www.circleid.com/posts/dns_resolution_browsers_hope_for_the_future/ >, then start discussing

  206. linuxwolf

    Zash: nice

  207. ralphm

    stpeter: nod

  208. stpeter

    linuxwolf: thanks for the reminder

  209. stpeter reads

  210. stpeter

    I mean, I had dinner with Andrew and a few other folks in Paris, but that was on a slightly different topic

  211. linuxwolf

    (-:

  212. linuxwolf

    it was the third most talked about topic for me in Paris

  213. linuxwolf

    and I really think everyone should care

  214. stpeter

    yep

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

  216. ralphm

    linuxwolf: interesting. Twisted implements its own resolver, partly because system calls are blocking

  217. linuxwolf

    ralphm: exactly

  218. linuxwolf

    "everyone" ends up doing their own, which all behave slightly differently, and give some us headaches

  219. Zash

    and prosody ...

  220. 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

  221. linuxwolf

    but I can tell you that "DNS people" don't see the current state of things as a problem, necessarily

  222. stpeter

    interesting, http://xmpp.org/extensions/xep-0086.html is deprecated, too (as is XEP-0093)

  223. stpeter

    I wonder if it's time to change 86 to Obsolete

  224. linuxwolf

    the amount of time spent talking past each other is a little astounding

  225. ralphm

    another trend is that recent versions of Ubuntu ship with dnsmasq by default

  226. linuxwolf

    can you tell my 15:30 meeting ended five minutes ago (-:

  227. stpeter

    quick meeting!

  228. linuxwolf

    daily scrum!

  229. ralphm

    linuxwolf: i.e. enabled by default

  230. Zash

    ralphm: I've installed a local resolver on all my boxes

  231. ralphm

    linuxwolf: with network-manager telling it the nameservers it should forward requests, too

  232. ralphm

    to

  233. 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

  234. linuxwolf

    the problem is not the resolver or nameservers, it's the libraries

  235. linuxwolf

    or the system calls

  236. ralphm

    I understand this

  237. linuxwolf

    (and the system calls?)

  238. linuxwolf

    sorry, this is a rage subject for me now (-:

  239. ralphm

    but this is an interesting approach as this gives it a better API than system calls: the DNS protocol

  240. linuxwolf

    dude, doing the DNS protocol properly is **HARD**

  241. stpeter

    regarding XEP-0130, I think we just assign it an expiration date, see http://xmpp.org/extensions/xep-0001.html#expiration

  242. ralphm

    better is subjective, of course

  243. ralphm

    richer is probably a better word

  244. linuxwolf

    I'd rather not have to think about YAP if I don't have to

  245. ralphm

    agreed

  246. linuxwolf

    I'd rather have a function or two I can call, and "magic" happens

  247. ralphm

    but not blocking

  248. linuxwolf

    also, lack of an API makes processing DNSSEC very very difficult

  249. linuxwolf

    well, lack of a library

  250. fippo

    linuxwolf: unbound

  251. linuxwolf

    then we might want to tack DANE on top of all that, and properly validate chains

  252. linuxwolf

    fippo: it lauches a new process, which means I can't use it everywhere I want to

  253. linuxwolf

    I've told them about it, too

  254. linuxwolf

    each request forks a new process to make the DNS request

  255. linuxwolf

    that is almost worse than blocking function calls in a lot of environments

  256. fippo

    linuxwolf: iirc it can use just a single background thread which runs an event loop

  257. Zash

    libunbound \o/

  258. linuxwolf

    fippo: it can, but I've found it difficult to get setup that way

  259. fippo

    (but doesn't give any means of integrating that loop into your own eventloop)

  260. linuxwolf

    and it's still spawning a new process

  261. linuxwolf

    it's eating up far more resources than just handling it async would

  262. linuxwolf

    less on Linux than Darwin or Mac

  263. linuxwolf

    er

  264. linuxwolf

    Darwin or Windows

  265. linuxwolf

    and using it on Android or iOS is …. troubleshome

  266. Kev

    Tobias has libunbound working on Android, I believe.

  267. linuxwolf

    I tried to get it to work for iOS and had issues

  268. linuxwolf

    at one point, I couldn't get it to compile in NDK, but that was a *long* time ago

  269. linuxwolf

    and, anyway, spawning a process (or a thread) to make something async is a resource-hogging cop-out

  270. linuxwolf

    "all" of the platforms (most of us care about) have a way to manage asynchronous I/O is a very efficient manner

  271. linuxwolf takes a breath, and directs this ire back at the folks who it should actually be directed at (-: