XMPP Council - 2012-02-15


  1. Tobias has left
  2. Tobias has joined
  3. Kev has left
  4. bear has joined
  5. bear has left
  6. Kev I'm having a somewhat distracted day. I'm not intending going anywhere, but in case I fail to notice the time later, could someone please send me a message when the time comes.
  7. Tobias sure
  8. Kev Thanks.
  9. stpeter has joined
  10. stpeter has left
  11. stpeter has joined
  12. linuxwolf goes looking for his graphite-powered legacy input device
  13. Kev Yees.
  14. stpeter dents and tweets
  15. Michael has joined
  16. linuxwolf this is going to bug me all day
  17. Kev On a yoghurt I'm about to eat (although it's a "0% fat" one, which seems to mean "tastes icky"): "suitable for vegetarians".
  18. Hirotaka Sato has joined
  19. Kev One assumes this is contrary to the usual bacon yoghurts, which aren't.
  20. linuxwolf well, there's vegetarians and there's Vegerians
  21. linuxwolf or vegans
  22. linuxwolf which wouldn't eat yogurt if any part came from an animal is some form … such as milk
  23. stpeter don't forget the fruitarians!
  24. linuxwolf vegitarivores and meatarians
  25. Kev linuxwolf: It doesn't claim to be suitable for vegans (which, given it's made from milk, would probably be difficult).
  26. linuxwolf very true
  27. linuxwolf I wonder if they removed all the bacteria … which wouldn't make it yogurt
  28. Kev They certainly removed all the nice.
  29. Kev I'm sure that when I was (much) younger, fruit yoghurts used to taste of fruit. Sometimes even the one advertised on the packaging.
  30. linuxwolf 0% fat is almost never a good idea
  31. Kev I didn't notice any fruit yoghurts that weren't fun-free :/
  32. linuxwolf when we were younger, fruit yogurts actually contained fruit
  33. linuxwolf now they have "natural and artificial flavors"
  34. Kev I *like* cherries.
  35. Kev I'm sure I do.
  36. Kev They taste fruity and nice.
  37. linuxwolf you're best bet is to get plain yogurt, add fruit, and blend
  38. guusdk has joined
  39. stpeter prefers plain, high-fat yoghurt
  40. linuxwolf maybe some honey too
  41. stpeter and how did we get on this topic? ;-)
  42. Kev Also: Bacon.
  43. Kev stpeter: I'm whining about eating a fun-free yoghurt.
  44. linuxwolf now I'm hugry
  45. guusdk hungry within a minute joining the xmpp council muc.
  46. linuxwolf let's get this over with so I can address that hunger thing
  47. Kev Yeah, I was until I tasted this yoghurt, too!
  48. linuxwolf I think I'll have a ham-and-cheese panini
  49. stpeter have we pinged Ralph and Matthew?
  50. Kev I have (just)
  51. ralphm has joined
  52. linuxwolf just pinged Ralph
  53. linuxwolf hehe
  54. stpeter oh shoot, gotta join the IETF Tools Team call
  55. Tobias pinged matt
  56. Kev Righty.
  57. MattJ has joined
  58. Kev 1) Roll call
  59. Kev I'm here!
  60. ralphm AOL
  61. linuxwolf presente
  62. MattJ Here!
  63. Tobias here
  64. Kev Amazing.
  65. Kev 2) Spec length
  66. Kev What to do about -45 and -60?
  67. MattJ Too long.
  68. Kev XEP-0312: TL;DR
  69. linuxwolf I doubt anyone will argue too short
  70. MattJ Well there are obviously only two things we can do: split or remove
  71. ralphm heh
  72. Kev Right, so, I don't argue with splitting MUC into essentially two - Administration and Usage or something.
  73. MattJ Makes sense
  74. Kev Although I'm not sure what it buys us, really, other than two shorter specs.
  75. Kev We want servers to implement all of it, regardless.
  76. Kev I suppose clients could just implement the non-admin bits (as Swift did for a while).
  77. linuxwolf I think we'd end up with some duplication, with regards to join/create
  78. MattJ Well splitting MUC makes less sense for others, I think
  79. MattJ *less sense than for others
  80. ralphm I haven't really considered splitting MUC
  81. MattJ OTOH I have a growing list of things I'd like to see removed from XEP-0060
  82. ralphm For XEP-0060 there are a lot of optional features
  83. ralphm that could be moved to their own spec
  84. linuxwolf yeah, XEP-0060 could benefit from breakup
  85. linuxwolf not sure about MUC right now
  86. Kev Ok, so is it fair to say that rough consensus is that -45 should be left alone, wrt. splitting it?
  87. MattJ I'm convinced there are a whole bunch of features in XEP-0060 that *nobody* is using
  88. ralphm there you have some very basic use cases that you can build upon
  89. Kev Splitting -60 seems fine to me, although I don't know it in enough depth to suggest where.
  90. MattJ I think MUC isn't too bad
  91. stpeter for MUC, I do think we could fairly easily split the dumb-client parts from the moderator/admin/owner use cases -- and *most* clients don't support any of the latter
  92. MattJ We just need to be sure not to add to it
  93. Tobias do you think the duplication would be much when splitting basic chat features and complex admin stuff for MUC?
  94. MattJ I wouldn't be opposed to an admin/user split of the spec
  95. Kev Tobias: Well, you've got room creation, kicking and things.
  96. linuxwolf stpeter: probably, although some discussion in the "dumb-client" spec would need to talk about create in some referential manner
  97. stpeter linuxwolf: for sure
  98. Kev So a dumb client may not be able to kick, but should still know what being kicked looks like.
  99. stpeter right
  100. linuxwolf yeah
  101. Tobias Kev, but these would only be added by the admin spec, wouldn't they...basic clients would still understand normal errors and such
  102. ralphm sure, you need to discuss roles etc in the core spec
  103. stpeter ralphm: true
  104. Kev So, my rough stance on this is that I'm not opposed to a sensible split for -45 into dumb client and admin, but that I think getting such a split would be hard work that I'm not looking forward to having to review, and very much want to not have to do.
  105. MattJ In fact the main advantage I see of splitting 45 as it stands is that we can experiment with e.g. defining other protocols for admin of a room/service
  106. stpeter so I think it might be useful to take a look at 45 and see what it would look like with the moderator/admin/owner stuff moved to a separate spec
  107. ralphm nod
  108. linuxwolf sure
  109. stpeter MattJ: yes, ad-hoc commands in MUC is on my list :)
  110. MattJ Mine too
  111. MattJ Below MAM :)
  112. stpeter heh
  113. linuxwolf changes 0.25USD to hildjj
  114. stpeter my workflow is slowing down with the impending end of my IESG term, so I'll have more time soon
  115. Kev Ok, so, pubsub everyone's happy with being split.
  116. linuxwolf s/changes/charges
  117. linuxwolf Kev: definitely
  118. Kev I don't think we need to discuss this further then, do we?
  119. linuxwolf not presently
  120. stpeter Kev: I can take a quick/rough pass at 45
  121. Kev I'll take -45 changes as they come, but I have assorted reservations that I'm happy to have removed by seeing something that works.
  122. stpeter Kev: I think it would be worth discussing 60
  123. stpeter clearly there's a lot in 60
  124. Kev stpeter: Now, or when we have some sort of split pencilled up so we can discuss it?
  125. stpeter well, have people looked at 60 and thought about how we might split it up?
  126. stpeter same kind of thing?
  127. linuxwolf how about we start with everyone's list of "please remove"
  128. ralphm a bit
  129. ralphm most of the configuration bits could be moved out
  130. MattJ I'm still in the process of XEP-0060 review
  131. stpeter i.e., admin/owner/etc. vs mere publish and subscribe?
  132. linuxwolf I've thought about it, but haven't gone into much detail
  133. Kev I haven't, I think everyone else here has a better grasp of pubsub than I do.
  134. ralphm for nodes, subscriptions and pre-conditions
  135. stpeter I think that pub and sub are pretty simple, really
  136. MattJ so I'll probably have a better list when I submit my feedback to the list
  137. ralphm stpeter: yeah
  138. stpeter ok
  139. stpeter so it sounds like we can circle back on this topic in a few weeks
  140. linuxwolf /nod
  141. stpeter and perhaps start a thread on the pubsub@ list?
  142. linuxwolf +1
  143. stpeter I can start a thread on muc@ when I take a rough pass at the split
  144. Kev 3) Last call on XEP-0267
  145. MattJ even for subscriptions... I think things like "multiple subscriptions" should be (re)moved (or at least fixed)
  146. ralphm I'd very much like to see XEP-0060 be a very stripped down spec that explains the core use case, with references to other specs for enhanced behaviour
  147. MattJ +100
  148. Tobias +1
  149. ralphm I'll have a pass at XEP-0060 and make a list
  150. stpeter ralphm: super
  151. Kev Do we have implementations of 267 deployed/used now?
  152. linuxwolf garzie
  153. linuxwolf grazie even
  154. linuxwolf gah
  155. linuxwolf Kev: I don't know
  156. stpeter Kev: there's an implementation in Prosody (experimental) but I've not yet had time to deploy it at xmpp.net
  157. stpeter I'd be happy to wait
  158. Kev I'm not opposed to Last Calling it I guess, but I'm unlikely to want to push it to Draft.
  159. MattJ and I haven't looked at it or tested it yet
  160. stpeter right
  161. ralphm two would be nice
  162. stpeter how about I test it out at xmpp.net first
  163. MattJ wfm
  164. linuxwolf +1
  165. Tobias sounds like a plan
  166. stpeter notes that we might need to think about this non-requirement requirement for multiple implementations and deployment experience before pushing something to Draft
  167. Kev Ok. I may even have comments about it, I think.
  168. ralphm stpeter: I think multiple implementations is still a great thing to have
  169. Kev I treat Experimental as "Not obivously broken" and Draft as "The way we have consensus on solving this", mostly (and Final as "done deal").
  170. stpeter ralphm: always, the question is: is that a requirement for advancement? XEP-0001 doesn't say that
  171. Kev I think the current state of 267 is that we don't know that this is the right way to do this as we've not tried it.
  172. stpeter but that's a topic for a future meeting
  173. stpeter Kev: probably
  174. Kev Or, to phrase it slightly better, it can't stop being Experimental until there's been an experiment.
  175. linuxwolf thought experiments can go far, but maybe not far enough
  176. ralphm right, so the non-requirement kinda makes it easier to assert if it is the right way to do a thing
  177. stpeter anyway
  178. stpeter I think we have a path for 267
  179. Kev We've explicitly made the bar to Experimental very low in recentish meetings.
  180. stpeter more experimentation on the way :)
  181. linuxwolf the bar as been lower (-:
  182. MattJ Kev, *ahem* :)
  183. ralphm Kev: I've never lowered the bar, I don't think it should be very high at all
  184. ralphm but draft should be
  185. linuxwolf I'm with ralphm
  186. Kev Right, that's what I said, isn't it?
  187. Kev We've discussed this recently and agreed that the bar to Experimental should be very low.
  188. ralphm right
  189. Kev It doesn't imply that Draft should be that low.
  190. linuxwolf yes, but some of us started very low, and others needed to move (-:
  191. Astro has joined
  192. ralphm so I am again arguing for actual implementations (plural) to move forward
  193. linuxwolf anyway, we're in general agreement, so let's move on (-:
  194. Kev I don't need multiple implementations to persuade me it's Draft ready - but it's the easiest way to persuade me.
  195. Kev linuxwolf: right.
  196. Kev 4) Last call on XEP-0297
  197. MattJ +1
  198. linuxwolf are there multiple implementations?
  199. stpeter (BTW, a quick visual comparison of http://xmpp.org/extensions/xep-0045.html#moderator and http://xmpp.org/extensions/xep-0045.html#statuscodes indicates that we'd cut about 40% of XEP-0045 by moving the moderator/admin/owner use cases)
  200. Tobias i don't know of a single implementation
  201. Kev linuxwolf: I think there are, actually, aren't there?
  202. stpeter (but I'll post to muc@ about that....)
  203. linuxwolf MattJ has one for Prosody
  204. linuxwolf right?
  205. MattJ and a client one in Verse
  206. Tobias ah...ok
  207. Kev As the BC guys are using MAM, which uses it.
  208. MattJ Zash wrote both
  209. linuxwolf /-:
  210. Tobias nice
  211. MattJ and yes, BuddyCloud
  212. linuxwolf ok then
  213. linuxwolf +1 for last call
  214. stpeter notes that we'll need 297 for Carbons
  215. Kev Right.
  216. linuxwolf I'll make my comments during LC
  217. Kev I'm ok with Last Calling this.
  218. stpeter that's why I'm interested in seeing this done
  219. linuxwolf which are related to Carbons
  220. ralphm http://archive.jabber.org/docs/proto-draft/envelope.html
  221. Tobias i gave it a read earlier and it made sense and sounds logical...so +1 for this
  222. ralphm was wat it reminds me off, and XEP-0033's claim that it supersedes that
  223. MattJ gives ralphm bonus points for citing archive.jabber.org
  224. ralphm Heh
  225. ralphm I've been around for a bit I suppose
  226. linuxwolf (-:
  227. linuxwolf I think I actually tried to implement that, too
  228. Kev I think we need -297 LC votes from Ralph and Tobias?
  229. ralphm I think, contrairy to its claim, that jabber:x:envelope might actually have implementation
  230. ralphm that said, I'm +1 on LC
  231. Tobias i'Ve only implemented / used XEP-0033 some years ago
  232. Tobias Kev, see 16:22
  233. Tobias +1
  234. ralphm this spec is richer and more well defined
  235. Kev Tobias: Ta.
  236. Kev Ok, moving ever onwarsd.
  237. ralphm especially the security considerations
  238. Kev Also, onwards.
  239. Kev 5) http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1399
  240. linuxwolf ralphm: envelope was only meant to be the addressing bits, −297 really does wrap another (message) stanza
  241. Kev Is that line redundant?
  242. Kev It looks it to me.
  243. ralphm linuxwolf: yeah, I suppose. It's just juggling elements :-)
  244. Tobias Kev, where is the same already said? or is the behavior described common sense?
  245. ralphm linuxwolf: one might argue that embedding a message in another element makes backwards compatibility harder
  246. Kev Tobias: There was a thread about this on the mailing list.
  247. MattJ I missed the thread
  248. Kev I wonder if I can find it.
  249. Kev But the summary was that the error it refers to doesn't exist.
  250. linuxwolf ralphm: that's what explicit namespace declarations are for (-:
  251. MattJ so am lacking any context or opinion (it seems sensible)
  252. linuxwolf I don't recall that jingle thread
  253. stpeter MattJ: we discussed this on the jingle@ list
  254. ralphm linuxwolf: as an aside, Blain Cook asserted the same thing about Atom payloads and pubsub events.
  255. Kev Nor is there anything in 166 that talks about encrypted streams to use this on.
  256. stpeter and on standards@
  257. linuxwolf checks his subscriptions
  258. stpeter wel
  259. ralphm linuxwolf: in that he'd like it better if the payload was outside the pubsub element
  260. stpeter actually
  261. stpeter http://mail.jabber.org/pipermail/standards/2012-January/025717.html
  262. stpeter that's the start of the thread
  263. stpeter so I only forwarded my conclusions to the jingle@ list
  264. Kev That's the one, thanks Peter.
  265. stpeter anyway, no hurry
  266. stpeter we can discuss next week
  267. stpeter or on the list
  268. linuxwolf yeah
  269. linuxwolf I need to rebuild my context
  270. Kev Ok.
  271. Kev 6) Date of next meeting.
  272. linuxwolf it was sent on my b-day … I ignored a lot of email that day (-:
  273. Kev SBTSBC?
  274. linuxwolf +1
  275. MattJ +1
  276. stpeter heh
  277. Tobias looks up what it means
  278. stpeter wfm
  279. linuxwolf Same Bat Time Same Bat Channel
  280. stpeter I assume it's same bat time, same bat channel
  281. Kev Tobias: I don't *think* it's an established acronym, just one I use.
  282. Kev linuxwolf: Right.
  283. ralphm I should be
  284. ralphm it
  285. linuxwolf Kev likes to channel Adam West
  286. Tobias ah...k
  287. Tobias +1 then
  288. Kev Tobias: We went through a period where I'd say "same bat time same bat channel" for this agenda item. So I started abbreviating.
  289. Kev 7) AOB?
  290. linuxwolf s/Adam West/William Dozier/
  291. linuxwolf no AOB from me
  292. MattJ nack
  293. Kev Nor anyone else, it seems.
  294. Kev Ok then.
  295. ralphm yay
  296. Kev Thanks all :)
  297. MattJ Thanks
  298. Kev gavels the hammer. Or something.
  299. linuxwolf goes back to lamenting the loss of his pencil
  300. linuxwolf now I don't know what to do when I'm pondering
  301. Kev I have some almost-yoghurt you could eat!
  302. stpeter heh
  303. linuxwolf I think I might have a fancy wood pencil
  304. linuxwolf aha!
  305. linuxwolf found my pencil bag
  306. stpeter linuxwolf: now that I'm using PGP more often, you and I might want to do a keysigning sometime ;-)
  307. linuxwolf that would require me to use PGP d-:
  308. stpeter linuxwolf: you usually sign your @cisco mail, don't you?
  309. linuxwolf I do
  310. linuxwolf CMS
  311. stpeter oh
  312. stpeter sees his inbox bump up over 30 messages and starts to scrub it
  313. linuxwolf (-:
  314. Astro did I read channels? buddycloud channels?
  315. ralphm Astro: bat channels
  316. stpeter :)
  317. linuxwolf looks at using PGP
  318. linuxwolf I can get my PGP key printed on my business cards, but not my cert
  319. stpeter linuxwolf: I go back and forth between PGP, S/MIME, and nothing
  320. stpeter linuxwolf: however, in my experience very very few people us S/MIME, whereas PGP is mildly useful for sending messages encrypted
  321. stpeter I even use openpgp for IM messages at times (at least with migri, who helps out with xmpp.org list administration)
  322. stpeter tests out the beta version of the IETF datatracker
  323. linuxwolf has left
  324. linuxwolf has joined
  325. Michael has left
  326. Astro has left
  327. guusdk has left
  328. Hirotaka Sato has left
  329. stpeter has left
  330. stpeter has joined
  331. Astro has joined
  332. linuxwolf has left
  333. Astro has joined
  334. ralphm has left
  335. linuxwolf has joined
  336. Astro has joined
  337. linuxwolf has left
  338. linuxwolf has joined
  339. linuxwolf has left
  340. Astro has left