XSF logo XMPP Council - 2013-03-20


  1. m&m has joined
  2. Tobias has left
  3. Zash has left
  4. m&m has left
  5. Tobias has left
  6. Tobias has joined
  7. Tobias has left
  8. Tobias has joined
  9. Tobias has left
  10. Tobias has joined
  11. Tobias has left
  12. Neustradamus has left
  13. Neustradamus has joined
  14. Tobias has joined
  15. Neustradamus has left
  16. Neustradamus has joined
  17. Zash has joined
  18. Kev has left
  19. Peter Waher has joined
  20. Kev has left
  21. Kev has left
  22. jabberjocke has joined
  23. Kev has left
  24. Neustradamus has left
  25. Neustradamus has joined
  26. Peter Waher has left
  27. Peter Waher has joined
  28. Peter Waher has left
  29. Peter Waher has joined
  30. Tobias has joined
  31. m&m has joined
  32. fippo has joined
  33. MattJ has joined
  34. Tobias has joined
  35. Peter Waher has left
  36. m&m might be a tad "late"
  37. m&m or unfocused right at the start
  38. Kev OK.
  39. Kev I'm *still* reviewing stuff.
  40. Dave Cridland has joined
  41. Dave Cridland Kev, Anyone would think you were busy these days, for some reason.
  42. Kev How little they would know.
  43. ralphm has joined
  44. Kev Right. 'tis time.
  45. Kev 1) Roll call.
  46. yusuke.doi has joined
  47. m&m present physically
  48. m&m er … logically
  49. ralphm hey
  50. ralphm from pycon
  51. Kev Ah.
  52. Kev Hail, pycon.
  53. Kev MattJ / Tobias?
  54. MattJ Present
  55. Kev Tobias is auto-away, I can tell because Swift has put a Zzz icon over his avatar :D
  56. Kev Right. So let's start.
  57. MattJ Does that mean he's asleep?
  58. Kev Probably.
  59. Kev 2) Let's start with the completely uncontentious one. LC on 220?
  60. MattJ +1
  61. m&m +1
  62. Kev I'm +1
  63. ralphm yea
  64. Kev Magic.
  65. m&m as I work on making db irrelevant (-:
  66. Kev 3) 308 to Draft?
  67. Kev I have, I believe, addressed all the LC feedback in one way or another.
  68. m&m I think so, too
  69. m&m I'm +1
  70. ralphm +1
  71. MattJ +1
  72. Kev Amazing.
  73. MattJ That wasn't the contentious item, was it? :)
  74. Kev 4) http://xmpp.org/extensions/inbox/dtls-fingerprint.html Accept as Experimental?
  75. Kanchil Kev: http://xmpp.org/extensions/inbox/dtls-fingerprint.html: XEP-xxxx: Use of DTLS-SRTP in Jingle Sessions
  76. m&m no objections
  77. Kev I know nothing about the subject matter, but that presumably just means I have no meanginful objections.
  78. Kev Or spelling.
  79. Dave Cridland I thought we had something like this already.
  80. Dave Cridland Or was that ZRTP?
  81. m&m ZRTP, IIRC
  82. Kev ZRTP.
  83. fippo dave: 0262 -- dtls is significantly different
  84. MattJ I've no objections so far, but that's likely because I only saw the document this morning and haven't read it through yet
  85. ralphm No objection
  86. Kev 5) http://xmpp.org/extensions/inbox/roster-management.html Accept as Experimental?
  87. Kanchil Kev: http://xmpp.org/extensions/inbox/roster-management.html: XEP-xxxx: Remote Roster Management
  88. Kev I have assorted issues with this, but I don't think they're fundamental to the design, they just need maturing on the vine.
  89. Kev I think fundamentally "use iq:roster" is right.
  90. m&m I haven't read it yet
  91. MattJ I'm +1
  92. MattJ It does have questions, but it's implemented in places and working
  93. ralphm No objection
  94. Kev I read something that I thought was broken, but I don't remember what it was. But I'm not objecting anyway.
  95. ralphm heh
  96. Kev It wasn't show-stopping.
  97. Kev m&m: So, a fortnight for you to object :)
  98. Kev 6) http://xmpp.org/extensions/inbox/sensor-data.html Accept as Experimental?
  99. m&m I'm not objecting now
  100. Kanchil Kev: http://xmpp.org/extensions/inbox/sensor-data.html: XEP-xxxx: Sensor Data Interchange over XMPP
  101. m&m (-:
  102. Kev m&m: Noted, ta.
  103. Kev This was the last on my list, and I've not got to it yet. Objections, or lack thereof, within a fortnight.
  104. m&m I glanced over this earlier … no objections
  105. ralphm No objection
  106. MattJ I've no objection to accepting
  107. MattJ I think it needs some work though
  108. ralphm indeed
  109. Kev I'd encourage people to post comments to the list :)
  110. ralphm but I like people are working on this stuff
  111. Kev In fact, not only would I, but I do!
  112. Kev 7) http://xmpp.org/extensions/inbox/exi.html Accept as experimental
  113. Kanchil Kev: http://xmpp.org/extensions/inbox/exi.html: XEP-xxxx: Using Efficient XML Interchange (EXI) Format in XMPP
  114. MattJ Yay!
  115. ralphm I haven"t looked at the exi stuff yet
  116. Kev I have some issues with this.
  117. Kev I'm trying to work out if they're sufficiently fundamental to object or not.
  118. Dave Cridland I'd note that while I think EXI may be mature enough (and useful enough) to consider now, I don't think this fits as a compression mechanism - ie, within the XEP-0138 model.
  119. ralphm right
  120. Kev I /think/ that at least none of this stuff can happen pre-auth.
  121. MattJ Dave Cridland, because of bootstrapping?
  122. MattJ Kev, why not?
  123. Kev (And pre-TLS)
  124. m&m dwd: I agree with you
  125. Dave Cridland MattJ, There's some negotiation going on, and all sorts.
  126. m&m also http://www.quickmeme.com/meme/3tfmdg/
  127. Kanchil m&m: http://www.quickmeme.com/meme/3tfmdg/: Southpark Instructor - if youre going to compress after encryption youre going to
  128. ralphm Dave Cridland:how would you use it, roughly?
  129. Zash m&m: haha
  130. Kev MattJ: Because you're sending assorted stuff to the server
  131. Kev m&m: Negotiation and layering don't need to be equivalent.
  132. Dave Cridland ralphm, What, use EXI? Or use EXI within the context of XMPP?
  133. Kev But you need to have verified the server's identity before you're going to be willing to download schemas.
  134. Kev And similarly it'll need to have authenticated you for the same.
  135. MattJ Good point
  136. m&m right
  137. ralphm Dave Cridland: latter
  138. Kev I do understand the basic principle that compressing data that's indistinguishable from random is a Really Good Idea.
  139. Dave Cridland Kev, I'm not sure that's true. You can exchange which schemas you're willing to support for compression without security risk, I *think*. Not sure though.
  140. Dave Cridland ralphm, I think it's possibly a new binding, as PSA discussed.
  141. Kev Dave Cridland: If I MITM to add somehow malicious schemas, and you download them after auth, that still seems bad.
  142. ralphm right
  143. Dave Cridland Kev, I don't know - the data is still authenticated, it's just it may be compressed in odd ways.
  144. m&m I could be wrong, but the compression could be to the point where a MITM could inject a schema that fundamentally changes the data
  145. MattJ You could start with a common mandatory schema for auth, and negotiate others after TLS+auth
  146. Kev I'm at least not sufficiently knowledgeable on this to be confident that it's not introducing some really nasty issues.
  147. MattJ Nevertheless, I don't object to accepting it
  148. MattJ I think it would be good for people to poke at it
  149. MattJ Enough are interested that I think it'll happen
  150. m&m exactly
  151. MattJ Though "enough" are a vocal minority I think :)
  152. Dave Cridland Right, I'm not sufficiently knowledgeable either. But I do think this is generally wrong; a "pure" EXI binding seems the appropriate construction.
  153. Kev I'll hold off for today, and get my thoughts in order within the fortnight.
  154. MattJ nod
  155. m&m dwd: that's my feeling, too
  156. Dave Cridland FWIW, I note yusuke.doi is present and might have some opinion.
  157. yusuke.doi Hi, am I allowed to speak?
  158. Kev yusuke.doi: Of course.
  159. ralphm yes
  160. ralphm Dave Cridland is not on the council, either
  161. yusuke.doi Thanks. I believe this proposal should be discussed more, either in experimental state or pre-XEP.
  162. ralphm having it on the list wouldnbe awspme
  163. yusuke.doi I have no clear opinion to accept or not, but I feel this proposal have slight variation from 'regular' EXI.
  164. ralphm yay lag and tablet
  165. m&m yusuke.doi: ??
  166. m&m that's a little concerning to me … XMPP already abuses XML stacks enough
  167. yusuke.doi m&m: I see :-) If it's okay for the committee, I don't object.
  168. MattJ m&m, for that suggestion I'll deal with you later :)
  169. Kev So, I think we need to take this to list. I'll try and post something soon, and see if I can form a sensible opinion within a fortnight.
  170. ralphm yeah
  171. MattJ Sounds good
  172. fippo m&m: shall i propose a asn.1 binding for xmpp? :-)
  173. ralphm sure
  174. m&m my problem is that I don't understand EXI enough to feel comfortable commenting
  175. Kev I'm not fundamentally opposed to the idea of EXI for XMPP, at least.
  176. yusuke.doi You need to invent namespace in asn.1 :-)
  177. ralphm and a protocol buffers oene
  178. Kev Right. I think we're done.
  179. Kev 7) Date?
  180. m&m protobuff!
  181. Dave Cridland yusuke.doi, X.693
  182. Kev 8) Date, rather
  183. Zash JSON!!
  184. m&m next week works for me
  185. ralphm sbtsbc
  186. yusuke.doi Dave Cridland: Thanks
  187. MattJ wfm
  188. Kev OK.
  189. Kev 9) AOB?
  190. MattJ nack
  191. m&m the IETF meeting was rather uneventful
  192. ralphm glad about per's message
  193. m&m mostly because it was the very last session of the week
  194. m&m and we were all brain-dead
  195. MattJ I noticed :)
  196. Kev OK, that's it then.
  197. Kev Thanks all.
  198. m&m someone has to be the sacrificial goat; RAI likes to rotate which group that is
  199. MattJ Thanks Kev
  200. yusuke.doi Thanks
  201. ralphm people at pycon are really cynical about Google's plans with XMPP
  202. Kev bangs the gavel.
  203. m&m I just want to know I think EXI for XMPP is interesting, but I'm not sure this is the right a approach
  204. Kev ralphm: Oh? This because of the somewhat political "Google Bad, Mkay" thing prominent people have done this week?
  205. m&m ralphm: I can't blame them
  206. ralphm yeah, many misinformed opinions
  207. fippo ralphm: as long as google doesn't put jarkko (the irc guy) in charge there is no reason to worry :-)
  208. ralphm hah
  209. m&m no comment (-:
  210. ralphm google reader thing and caldav didn't go over well, and then this came up
  211. Dave Cridland CalDAV isn't being dropped, though.
  212. Zash Just require you to be whitelisted to access?
  213. Dave Cridland I'm told that it's being moved to an Oauth2 based service, but the transition just happens to be a bit rough.
  214. ralphm well that's entirely different from what they wrote themselves
  215. Dave Cridland Once it's OAuth2, it will have per-application keys, though I don't know the details.
  216. yusuke.doi m&m: I'd like to propose different port approach for EXI with XMPP soon.
  217. m&m yusuke.doi: that sounds like the alternative binding route … which is probably the right approach
  218. ralphm in the announcement they said move to the google calendar api
  219. yusuke.doi m&m: depends on use case (is the fair answer, I believe alternative binding should be better :-)
  220. Dave Cridland ralphm, Yes, they did. I think the road to OAuth2 CalDAV is long and rocky.
  221. ralphm ok, but communicating that would've been nice
  222. ralphm oh well
  223. ralphm gotta walk to sprints now
  224. Kev Enjoy.
  225. MattJ m&m, by the way - a question that came up after IETF: as an implementor, how would I actually use POSH? Am I supposed to fire off HTTPS requests every time I see an invalid cert?
  226. MattJ See you ralphm
  227. fippo mattj: i think so
  228. MattJ m&m, or will we have a way in XMPP to hint that POSH should be used to verify?
  229. m&m MattJ: or everytime you see a new domain
  230. Dave Cridland yusuke.doi, I don't see nearly as many benefits for in-stream negotiated EXI, since you need a traditional XML parser, fallback cases, and so on. Feels all wrong.
  231. Zash MattJ: Just as we would need to fire off a DNS lookup for DANE
  232. MattJ Do both at the same time, and see which returns faster? ;)
  233. m&m basically, yes
  234. yusuke.doi Dave Cridland: Personally I agree. But Peter should have different answer
  235. m&m Happy Eyeballs for Everyone!
  236. MattJ Doesn't it essentially make everyone with a cert their own CA? :)
  237. fippo mattj: you might even do traditional dial-back in parallel :-)
  238. m&m it's the Oprah paradigm for protocols
  239. Zash MattJ: DANE? Yes. :D
  240. m&m DANE definitely does, POSH could depending on what other HTTP-based things you support
  241. fippo even though i think that the samecert stuff might be faster than POSH (less secure though sincc it works with self-signed certs)
  242. m&m fippo: dialback is not a prooftype
  243. MattJ fippo, samecert?
  244. fippo m&m: not for the ietf at least ;-)
  245. m&m fippo: not for anyone that actually cares about assurances d-:
  246. MattJ Neither for Prosody, as of the next version
  247. MattJ It's also an open question as to whether we allow dialback by default in the config
  248. fippo mattj: open a reverse connection to the host, starttls, compare certificates. slighty better than 0185, less roundtrips
  249. MattJ But either way it's motioning towards being called "insecure"
  250. fippo m&m: well, 99%+ of server admins don't care
  251. m&m wanders back to his day job responsibilities
  252. MattJ fippo, ah, right
  253. Zash !xep 185
  254. fippo m&m: shall i point out that muc.xmpp.ogr was using an invalid cert until like two weeks? :-)
  255. Kanchil Zash: XEP-0185(N/A): http://xmpp.org/extensions/xep-0185.html Dialback Key Generation and Validation - Informational/Active - Updated: 2007-02-15
  256. MattJ fippo, it wouldn't have been if nobody could connect to it :)
  257. MattJ Someone needs to jump first
  258. m&m right
  259. Zash Is samecert documented somewhere?
  260. fippo yeah. that big hammer called "jabber.org" ;-)
  261. MattJ fippo, well yes, there is that
  262. fippo zash: dave had a blogpost describing it...
  263. MattJ I was thinking of shipping XMPP servers, but jabber.org would be a better hammer
  264. Tobias Kev, yeah..the zZz meant i was asleep..sry
  265. MattJ or Google, but... meh
  266. Zash fippo: orly?
  267. Zash Dave Cridland: orly?!
  268. Zash Wasn't that d-w-d, which iirc was about verifying certs as normal
  269. Zash But in a dialback
  270. m&m that's what I thought
  271. fippo i think it descried samecert, too
  272. Zash Dave Cridland: Your blog, when will it return to the land of the online?
  273. fippo m&m: btw, DNA still needs a turbohalibut prooftype, otherwise that cridland guy will block it :-)
  274. m&m goes off for more caffeine
  275. fippo http://jabber.soup.io/post/88601075/Dave-Cridland-Dialback-Now-without-dialback -- cached version
  276. fippo the third paragraph describes samecert
  277. Zash And as I said at the summit, I'd like to see "If the SRV record is Secure, then the target name is acceptable in the certificate" in a standalone document :)
  278. Dave Cridland Tubrohalibut. Mmmmm.
  279. Dave Cridland Zash, So, my blog is more or less shot. I might resurrect it at some point. Or I might do something odd with having it semi-present and backed onto G+.
  280. Kev nanoc!
  281. Kev (Nanoc really does seem to be quite competent)
  282. Dave Cridland It's really that I'm not sure I can be bothered having a traditional blog, rather than G+.
  283. Zash It wouldn't be the same :(
  284. Zash But then, I'm in the 'doesn't really want to depend on Google'-crowd.
  285. fippo we should have recorded peters statement on open federation at the summit
  286. Zash fippo: summary? not sure I recall
  287. fippo zash: i don't recall exactly either :-( maybe webex was active and is recorded
  288. MattJ One day I'll finish my blog
  289. MattJ http://blog.matthewwild.co.uk/
  290. Kanchil MattJ: http://blog.matthewwild.co.uk/: Matthew Wild's Blog
  291. Tobias haha
  292. Zash !
  293. Tobias that reminds me of http://216.119.142.188/~jbwp/wp-content/uploads/2011/05/2011-05-01-Homer-Web-Page.jpg
  294. Tobias but sure beats the design of my blog
  295. yusuke.doi has left
  296. Zash has left
  297. fippo has left
  298. Tobias has left
  299. Tobias has joined
  300. Tobias has left
  301. Tobias has joined
  302. Lance has joined
  303. m&m has left
  304. Lance has left