XMPP Council - 2011-03-23

  1. julm has left
  2. julm has joined
  3. bear has left
  4. bear has joined
  5. Kev has left
  6. Kev has joined
  7. Tobias has joined
  8. Tobias has left
  9. stpeter has joined
  10. Tobias has joined
  11. MattJ has joined
  12. linuxwolf has joined
  13. stpeter T-15 minutes?
  14. MattJ Aye
  15. Kev Yes please.
  16. stpeter posted to identi.ca
  17. stpeter I just processed the forwarding proposal, too
  18. Kev !agendaappend http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP?
  19. Kanchil+ Kev: Done.
  20. Kev stpeter: So I saw :)
  21. MattJ Thanks :)
  22. Kev Indeed, murky.
  23. stpeter also, I received a bug report on the XEP-0198 schema so I processed that just now
  24. Florob has joined
  25. linuxwolf cutting the submission awfully close (-:
  26. waqas has joined
  27. stpeter heh
  28. stpeter could be considered next week or week after
  29. MattJ It's a small XEP!
  30. MattJ But really, I don't mind :)
  31. linuxwolf "I don't know if I can consider it at this late stage…"
  32. Kev It is a small XEP, and Peter announced that Council would vote today, so I have to put it on the agenda :)
  33. linuxwolf j/k… (-:
  34. stpeter I haven't looked at how the new http://xmpp.org/extensions/inbox/forwarding.html differs from the old http://xmpp.org/extensions/inbox/forwarding-delivery.html and http://xmpp.org/extensions/inbox/forwarding-request.html
  35. stpeter brb
  36. Kev stpeter: It's just an encapsulation format (unlike forwarding-request) to be used in other XEPs (like the upcoming Message Archive Management), and it's a straightforward complete encapsulation, unlike forwarding-deliver.
  37. linuxwolf mmmm….competing specs!
  38. linuxwolf Kev: and I have yet another BCP I'd like to propose
  39. Kev I have people working on the 'back yard' at the moment, so I'm sorry if I have to vanish at an inopportune moment for a couple of minutes.
  40. Kev linuxwolf: Good. You have 9 minutes.
  41. MattJ Hey, that's not fair
  42. linuxwolf (optional) version info via caps URL
  43. linuxwolf MattJ: do you see me presenting an actual spec? (-:
  44. MattJ linuxwolf, thankfully no, I want to hold the record for shortest submission->vote->acceptance for at least a short time :)
  45. linuxwolf in that case, I might just have to defer acceptance… (-:<
  46. MattJ You wouldn't :(
  47. linuxwolf is feeling snarky
  48. Kev I hope snarky is over-age, then.
  49. linuxwolf MattJ: use of reverse smileys may dissuade me from delay
  50. MattJ
  51. Kev (-:<
  52. stpeter aha, I see what you're after in http://xmpp.org/extensions/inbox/forwarding.html -- that's quite straightforward
  53. Florob 😸
  54. stpeter the old specs were about stanza forwarding a la .forward
  55. Kev Right.
  56. Kev So e.g. carbons should use this format.
  57. Kev As ideal, should the ad-hoc for forwarding unread messages.
  58. Kev As should 136bis
  59. stpeter +1 to 136bis
  60. linuxwolf well, carbons could use the older forwarding specs, too
  61. MattJ 136bis is on the way... I know because one of the few remaining todo items is "choose a title" :)
  62. stpeter I was mentioning just yesterday how we need to de-ian-ize certain specs like 136
  63. linuxwolf but I prefer the form from Messers WIld and Smith
  64. stpeter (mentioning to linuxwolf that is)
  65. Kev Matt's approach is to deny 136 ever existing. :)
  66. linuxwolf lol
  67. Kev Which suits me fine.
  68. MattJ It's not like it's seen wide adoption (and it's not hard to see why)
  69. MattJ I'm mostly excited about the new protocol simply because finally people might implement archiving
  70. linuxwolf maybe
  71. linuxwolf (-:
  72. stpeter I just invited Fritzy
  73. MattJ I'd love it to become a more mainstream feature - it's a really common request from users
  74. fritzy has joined
  75. stpeter :)
  76. stpeter hi Nathan!
  77. linuxwolf it definitely is
  78. Kev MattJ: Well, I want it in Swift, at least. Especially when used with the rest of the multi-resource stuff.
  79. MattJ That, and "I want my conversations to appear in all my clients"
  80. stpeter no sign of Mr. Meijer
  81. fritzy Howdy
  82. Kev I have to AFK for a moment, I'll be back within 2mins or so.
  83. stpeter MattJ: forwarding is a really common request, or history?
  84. linuxwolf history
  85. linuxwolf (logging, auditing, caching, ....)
  86. MattJ stpeter, history
  87. stpeter nod
  88. stpeter just checking
  89. MattJ Forwarding would be a nice addition to clients in itself, but I suspect users are just going to continue with their copying and their pasting :)
  90. Kev Right.
  91. Kev Let's start :)
  92. Kev !agendaup
  93. Kanchil+ Kev: -9) Fini.
  94. Kev !agendaup 10
  95. Kanchil+ Kev: 1) Roll call
  96. linuxwolf here
  97. MattJ Here
  98. fritzy howdy
  99. fritzy I mean here
  100. Kev !agendaup
  101. Kanchil+ Kev: 2) Agenda bashing
  102. linuxwolf request to talk about caps
  103. linuxwolf )(see above)
  104. Kev Is that a real item or AOB? :)
  105. linuxwolf it can be an AOB
  106. Kev Ok.
  107. Kev Anyone else?
  108. fritzy nossir
  109. stpeter it's hard to bash an agenda that we can't see :)
  110. MattJ Nope
  111. MattJ Gah, brb 60 sec
  112. fritzy we're blind?
  113. Kev stpeter: Well, I sent it out earlier in the week.
  114. Kev Plus the item you added today :)
  115. Kev But sure
  116. Kev !agenda
  117. Kanchil+ Kev: 1) Roll call 2) Agenda bashing 3) XEP-0065: Accept version 1.8? 4) http://www.xmpp.org/extensions/inbox/resource-locking.html Accept as XEP? 5) http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP? 6) Date of next meeting 7) Any other business Fini
  118. linuxwolf one could !agenda
  119. linuxwolf heh
  120. stpeter many thanks
  121. remko has joined
  122. stpeter seems fine to me
  123. Kev !agendaup
  124. Kanchil+ Kev: 3) XEP-0065: Accept version 1.8?
  125. Kev I haven't reviewed the diff. I'll do so and on-list it up.
  126. fritzy me neither
  127. Kev I'll also wait for MattJ for a moment before moving on.
  128. linuxwolf and neither have I
  129. stpeter the diff is hard to read, I find
  130. Kev Does anyone object to waiting for a moment for Matt to catch up?
  131. stpeter fine by me
  132. linuxwolf (defeaning silience)
  133. linuxwolf /sigh
  134. waqas chooses not to object
  135. fritzy I'm easy
  136. linuxwolf I've got too many docs to write today to be typoing
  137. MattJ Sorry, back
  138. Kev !agendaup 0
  139. Kanchil+ Kev: 3) XEP-0065: Accept version 1.8?
  140. Kev MattJ: ^
  141. MattJ I have it open, I haven't finished reviewing it, so I'll post on-list too
  142. Kev !agendaup
  143. Kanchil+ Kev: 4) http://www.xmpp.org/extensions/inbox/resource-locking.html Accept as XEP?
  144. Kev I don't object.
  145. Kev I'm not entirely convinced by each of the details, but I don't object :)
  146. fritzy +1
  147. linuxwolf +1, obviously (-:
  148. MattJ I don't object either, but I have some small feedback I'll post to standards@ when it's published
  149. Kev Specifically, I think it should always lock when receiving a new message, rather than maybe locking and maybe unlocking.
  150. stpeter BTW the most up-to-date diff for 65 is http://xmpp.org/extensions/diff/api/xep/0065/diff/1.7/vs/1.8rc4
  151. Kev I'm also not sure that <gone/> justifies an unlock, but I'm less worried about that.
  152. stpeter (but it's close to unreadable)
  153. linuxwolf Kev: to be fair, this is based on 10+ experience (-:
  154. Kev I'm happy to not really worry about this, as I think the later multi-client XEP solves all problems ;)
  155. linuxwolf (well, not specifically with <gone/> itself, but the entire concept)
  156. linuxwolf we shall see (-:
  157. Kev This is *almost* what we're doing in Swift.
  158. Kev Apart from not bothering with gone yet, and rebinding instead of unbinding on a new message.
  159. Kev Anyway.
  160. Kev !agendaup
  161. Kanchil+ Kev: 5) http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP?
  162. Kev +1 :)
  163. linuxwolf hmmm
  164. Kev The background for this:
  165. Kev Matt's got a new archiving spec, there's carbons, there's an ad-hoc for forwarding messages.
  166. Kev It'd be good to have a common format for the forwarded messages in each of these cases.
  167. Kev Thus this spec
  168. linuxwolf +1 actually
  169. fritzy +1
  170. linuxwolf I think I still have some security concerns, but I haven't exactly had a lot of time to read it (-:
  171. Kev linuxwolf: It's a format rather than a protocol.
  172. stpeter linuxwolf: sure, the interaction with signing and encryption might be "interesting"
  173. Kev So I think the security concerns belong to the protocol using the format, but I could be persuaded otherwise.
  174. Kev MattJ: Your vote? :)
  175. linuxwolf Kev: technically, it's a protocol extension format
  176. linuxwolf (-:
  177. fritzy does this technically change the jabber:client ns?
  178. Kev fritzy: Of course not.
  179. fritzy allowing another <message /> child?
  180. MattJ fritzy, it does not, why?
  181. Kev jabber:client says nothing about the number of message children.
  182. MattJ plus it's a child of a child
  183. fritzy right, that's not what I meant
  184. MattJ of another namespace
  185. MattJ so another schema (forwarding) applies
  186. stpeter http://tools.ietf.org/html/rfc3922 already had <presence/> within <presence/> (but a different namespace)
  187. MattJ AIUI
  188. MattJ Kev, +1 surprise, surprise! :)
  189. fritzy Oh, you're right MattJ.
  190. Kev Excellent.
  191. Kev !agendaup
  192. Kanchil+ Kev: 6) Date of next meeting
  193. Kev Ok, so, daylight savings change.
  194. MattJ Next week suits me
  195. linuxwolf heh
  196. Kev So I propose next Wednesday at 1500GMT.
  197. fritzy Wed 1600 Kevin Time. If he's in an unusual timezone for him, so help us all.
  198. linuxwolf notes that some of us already went through a TZ change
  199. stpeter notes that he'll go through the time change again in Prague on Sunday morning
  200. Kev linuxwolf: Indeed. That's why I noted just before the US started changing that we weren't shifting Council yet :)
  201. MattJ 1500GMT? Why the change?
  202. Kev MattJ: So it remains 4PM UK time.
  203. MattJ I never change my clocks for DST :)
  204. stpeter heehee
  205. stpeter good for you
  206. linuxwolf MattJ: that explains a lot (-:
  207. MattJ Heh
  208. stpeter I just use the sundial in my back yard
  209. MattJ Ok, I'm happy with 1500GMT next week
  210. Kev Is everyone happy with this?
  211. stpeter so 15:00 GMT?
  212. fritzy sure
  213. MattJ or to use the sundial in stpeter's back yard
  214. stpeter heh
  215. stpeter edits ./council/events.xml
  216. linuxwolf fine either way
  217. Kev stpeter: Thanks.
  218. Kev !agendaup
  219. Kanchil+ Kev: 7) Any other business
  220. linuxwolf ok
  221. Kev linuxwolf !
  222. stpeter it's doubtful that I'll attend next week's meeting
  223. Steffen Larsen has joined
  224. fritzy ok
  225. linuxwolf so, I'd like to propose a caps URL format recommendation, if clients are interested in reporting version/platform info
  226. stpeter let's see, I'll be in the CORE WG session at that time
  227. Kev stpeter: Enjoy Prague :)
  228. stpeter I shall, thanks :)
  229. stpeter anyway
  230. stpeter linuxwolf?
  231. linuxwolf is slightly jealous
  232. linuxwolf oh yes, so
  233. stpeter we need CSN in these meetings :)
  234. Kev stpeter: I said that last week.
  235. linuxwolf RT: linuxwolf: so, I'd like to propose a caps URL format recommendation, if clients are interested in reporting version/platform info
  236. Kev linuxwolf: Right, I'm waiting for your next line after that :)
  237. MattJ linuxwolf, I don't understand, please continue
  238. stpeter (calendar updated)
  239. linuxwolf hold on…shooing away IRL trolls
  240. stpeter heehee
  241. stpeter isn't in the office today, so it's not my fault
  242. MattJ Grab a piece of chalk and draw a circle around your desk
  243. linuxwolf ok, so the idea is to inconspicuously indicate the version/platform via "query parameters" to the caps node URL, assuming a client sends a URL (per recommendations)
  244. stpeter is favor of just about anything that kills off iq:version
  245. fritzy haha
  246. linuxwolf e.g. http://outer-planes.net/matts-magical-client?v=2011.03.12314&p=linux
  247. MattJ loves iq:version, long live iq:version!
  248. linuxwolf and doesn't impact the actual caps hash
  249. stpeter :)
  250. linuxwolf yeah, I'd like to see iq:version DIAF
  251. MattJ linuxwolf, ok, why this?
  252. waqas I would like to fix caps hashes :)
  253. linuxwolf MattJ: because large organizations like to know what clients their users are logging in with, without laying down the lockout hammer
  254. stpeter yes, we do need to fix the security hole that waqas found
  255. linuxwolf definitely
  256. Kev So, I have no particular opinion on this until I've seen some examples.
  257. linuxwolf RT: linuxwolf: e.g. http://outer-planes.net/matts-magical-client?v=2011.03.12314&p=linux
  258. Kev Yeees.
  259. Kev I meant slightly more of an exposition than that :)
  260. stpeter heh
  261. stpeter looks forward to a mini-spec on the topic or a patch to 115
  262. linuxwolf or, say, http://ww.cisco.com/go/jabber?v=8.0.3&p=mac
  263. MattJ linuxwolf, why not just file a bug with the relevant clients?
  264. MattJ Say "it would be really nice if you included the version and platform in your caps url"
  265. linuxwolf well, it's hard to file a bug if there's not defined (recommended) format
  266. Kev I don't think I have any particular objections to this, I'd have to sit down with 115 and the new spec and be sure there's no unfortunate interactions.
  267. linuxwolf and I likely would…it would be nice for us to agree to a general format
  268. Kev So...bring on the spec :)
  269. linuxwolf well…so with the 115 problems
  270. MattJ I don't see why we need to define such a format, it's not for interop and I don't think anyone is going to enforce it
  271. linuxwolf do we want a separate spec, or an implementation detail within 115 (as we fix 115)
  272. Kev MattJ: You can say the same about iq:version :)
  273. linuxwolf MattJ: It actually is for interop
  274. MattJ Kev, I bet someone, somewhere, has used iq:version for interop
  275. Kev linuxwolf: I *think* a sidenote in 115, but I don't feel strongly.
  276. linuxwolf iq:version needs to DIAG (-:
  277. linuxwolf I can go either way
  278. linuxwolf fixing 115 is not a small task
  279. Kev I don't think I know DIAG. What's 'G'?
  280. linuxwolf gah
  281. Kev Ah.
  282. linuxwolf DIAF
  283. linuxwolf Gulag?
  284. Kev No, I like DIA Gah
  285. linuxwolf lol...literally
  286. linuxwolf ok
  287. Kev Anyway, I think we're vaguely done with this are we?
  288. fritzy there you go
  289. linuxwolf so, I (or some minion) can writeup a tiny XEP about it
  290. Kev linuxwolf: Sure.
  291. linuxwolf I don't know if I want to tackle fixing hashes at the same time we add this note
  292. MattJ Sounds like a plan
  293. stpeter ah, to have minions
  294. fritzy that'd be nice
  295. Kev So
  296. linuxwolf technically, my minions are loaned to me
  297. Kev !agendaup 0
  298. Kanchil+ Kev: 7) Any other business
  299. linuxwolf /fini
  300. fritzy !done
  301. fritzy or wait, is that not-done?
  302. Kev !agendaup
  303. Kanchil+ Kev: 8) Fini.
  304. Kev Thanks all :)
  305. Kev bangs the gavel
  306. linuxwolf adios
  307. Kev !agendaup -8
  308. Kanchil+ Kev: 0) Fini.
  309. MattJ Wow, on the dot
  310. Kev !agendaclear
  311. Kanchil+ Kev: Done.
  312. linuxwolf goes off to read a dictionary, hopefully soaking in better spelling mojo
  313. stpeter returns to his review of OAuth spe s
  314. stpeter specs even
  315. linuxwolf feels less horrible now…thanks stpeter (-:
  316. stpeter :P
  317. linuxwolf has left
  318. fritzy cio
  319. fritzy has left
  320. stpeter who is the cio?
  321. bear that's an italian typo - he meant ciao
  322. stpeter I figured :)
  323. stpeter although my Czech friends spell it "čau" :)
  324. Neustradamus has joined
  325. Tobias has left
  326. remko has left
  327. Steffen Larsen has left
  328. Steffen Larsen has joined
  329. Tobias has joined
  330. Steffen Larsen has left
  331. Kev has left
  332. Kev has joined
  333. bear has left
  334. bear has joined
  335. Tobias has left
  336. Florob has left
  337. Florob has joined
  338. Tobias has joined
  339. Tobias has left
  340. Tobias has joined
  341. Tobias has left
  342. stpeter has left
  343. ralphm has joined
  344. ralphm has left
  345. Tobias has joined
  346. mlundblad has joined
  347. Neustradamus has left
  348. Tobias has left