XMPP Council - 2013-09-25


  1. stpeter has joined
  2. stpeter has left
  3. stpeter has joined
  4. stpeter has left
  5. Lance has joined
  6. Lance has left
  7. m&m has joined
  8. stpeter has joined
  9. stpeter has left
  10. m&m has left
  11. stpeter has joined
  12. tato has joined
  13. stpeter has left
  14. stpeter has joined
  15. Lance has joined
  16. Tobias has left
  17. stpeter has left
  18. stpeter has joined
  19. stpeter has left
  20. bear has left
  21. bear has joined
  22. Lance has joined
  23. Kev has joined
  24. bear has left
  25. Tobias has left
  26. tato has left
  27. ralphm has left
  28. ralphm has joined
  29. Tobias has joined
  30. Tobias has left
  31. Tobias has joined
  32. Lance has joined
  33. Lance has left
  34. tato has joined
  35. tato has left
  36. stpeter has joined
  37. stpeter has left
  38. m&m has joined
  39. Zash has joined
  40. stpeter has joined
  41. stpeter has left
  42. stpeter has joined
  43. stpeter has left
  44. Peter Waher has joined
  45. Zash has joined
  46. jabberjocke has left
  47. jabberjocke has joined
  48. jabberjocke has left
  49. Zash has joined
  50. Tobias are there any outstanding votes from me?
  51. Kev Not for another 2 minutes :)
  52. Tobias great
  53. m&m ding
  54. Tobias dong
  55. Tobias the witch is dead
  56. m&m the witch is dead
  57. m&m dammit
  58. Kev Which old witch?
  59. Kev 1) Roll call!
  60. MattJ Present
  61. m&m presente
  62. Tobias here
  63. Kev Le Ralph?
  64. ralphm here
  65. Kev Marvellous.
  66. m&m yay!
  67. Kev 2) http://xmpp.org/extensions/xep-0297.html Advance to Draft?
  68. Kanchil Kev: http://xmpp.org/extensions/xep-0297.html: XEP-0297: Stanza Forwarding
  69. m&m +1 from me
  70. MattJ +1
  71. Tobias +1
  72. ralphm +1
  73. Kev I'll double check before sending +1 to list.
  74. Kev I think that was the only voting action this week.
  75. Kev So unless I missed one...
  76. Kev 3) Date of next meeting
  77. m&m SBTSBC WFM
  78. Tobias wfm
  79. Kev Excellent.
  80. MattJ ditto
  81. ralphm yay
  82. Kev ralphm?
  83. Kev OK.
  84. Kev 4) AOB.
  85. MattJ Yes, my outstanding votes need recording :)
  86. m&m I notice the Board and Council nominees are thin
  87. Tobias do we already have a new version of RTT to read/vote on or will a last call be reissued?
  88. MattJ I'm +1 on 220 and 288
  89. Kev The 301 authors have submitted another version to Peter to address m&m's comments, although not my last remaining comment (which I first raised ages ago).
  90. Kev Tobias: Was already typing :)
  91. Kev FWIW, my remaining comment (which didn't go to list because I was replying to a mail they didn't send to list, accidentally) was:
  92. Kev I'm sorry for being a nuisance yet again, but I have one remaining nit. At the end of 6.1 you have the ...MAY implicitly request... e.g. when...invisible/offline. Can you tighten this up just slightly to be clear that implicit discovery is only allowed when normal discovery isn't possible? I suggest this tweak: "While explicit discovery is strongly RECOMMENDED (see Determining Support), the sender client MAY implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation" -> "While explicit discovery is REQUIRED (see Determining Support) where possible, it is not possible to use explicit discovery when the sender does not share a presence subscription with the the contact and knows only their bare JID (e.g. they have yet to receive stanzas from the contact). In this case, the sender client MAY implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation" I think this keeps your ability to discover implicitly when explicit discovery isn't possible, but maintains that in all other cases you need to do explicit discovery.
  93. ralphm I'm +1 on 220 and 228 as well
  94. Kev I feel fairly strongly that we shouldn't be introducing another pseudo-discovery mess like 85 here. (85 became a mess because 115 didn't exist when it was published, and we needed to maintain backwards compatibility).
  95. m&m 115 and decloaking
  96. ralphm Kev: this came up before, and I agree
  97. Kev Having worked on a couple of 85 implementations I don't think that confusion is helpful.
  98. Tobias i think discovery should be used where possible...if they don't want expensive discos they can ship their clients with precalculated caps databases
  99. MattJ Makes sense to me
  100. Kev ralphm: It did, but the authors didn't really address it last time (and haven't this time), claiming they need to be compatible with -85.
  101. waqas has joined
  102. Kev m&m: I thought about saying they should be using decloaking, but I can also see the argument that decloaking hasn't actually gone anywhere.
  103. ralphm How is that even an issue? Clients that implement XEP-0085 will, eh, implement XEP-0085.
  104. Kev ralphm: Right, I don't think my proposed text means there's ever a case where you could do -85 but couldn't do -301.
  105. Kev I'd like to keep blocking until this is addressed, so I'm presenting it here so the rest of Council can talk me down if they disagree with me.
  106. Kev But it doesn't seem like they do :)
  107. Zash So, 280 (and 313) could move forward now? (If Kev +1es)
  108. ralphm Kev: I support your -1.
  109. m&m Zash: in theory
  110. m&m Kev: hold the line
  111. Kev Zash: I think they can go to LC, if the authors request it, yes.
  112. Kev ralphm / m&m: Ta.
  113. MattJ 313 isn't quite ready yet, I have a new version I need to push
  114. Kev OK. I note Ralph and Matt's votes from earlier, will minute.
  115. MattJ But then it'll be ready
  116. ralphm Kev: that kind of moves this to 'Rejected', right?
  117. Kev Anything else for AOB?
  118. Tobias could we have the votes on our votes page?
  119. m&m I notice the Board and Council nominee list is thin
  120. Kev ralphm: If we're following the letter of XEP-0001 (which we never do), it would, yes. But I'm happy with the usual "We'll just keep it in Proposed until all feedback is addressed".
  121. Kev ralphm: What are your thoughts?
  122. MattJ Does XEP-0001 need updating to reflect this process then?
  123. ralphm Kev: practically, how could a spec ever move to rejected?
  124. Kev m&m: Yes, seems so. I'll apply to Council again. I'm aware of people being poked for Board behind the scenes.
  125. stpeter has joined
  126. stpeter has left
  127. Tobias referring to this page http://xmpp.org/about-xmpp/xsf/xmpp-council/twelfth-council/
  128. Kanchil Tobias: http://xmpp.org/about-xmpp/xsf/xmpp-council/twelfth-council/: Twelfth Council &#8211; The XMPP Standards Foundation
  129. Kev ralphm: Only if we decided during LC that it wasn't ever going to be appropriate to move to Draft, I think.
  130. ralphm hm
  131. Kev Tobias: I think Peter usually maintains that page. I'm sure he'd appreciate a volunteer, if you are :)
  132. Tobias sure...but i have no clue who voted what :)
  133. Kev MattJ: I think probably updating XEP-0001 to match reality is desirable. Although given the imminent departure of Board, it might be best to wait for next term.
  134. Kev Tobias: The minutes :)
  135. Zash m&m: Know of any issues with 280?
  136. Kev Tobias: If you want to take this on, I'd suggest poking Peter.
  137. ralphm I was planning on running for Council
  138. stpeter has joined
  139. MattJ Zash, m&m: might hate me for this, but it doesn't use hints
  140. stpeter (sorry, I got delayed and I'm also on a conference call)
  141. ralphm hey stpeter
  142. Kev Hi Peter.
  143. m&m Zash: I think fippo and cridland (in a previous life) worked out most of the technical hurdles, and the latest draft reflects this
  144. m&m I can live without hints (-:
  145. Kev I'm not sure where we are meeting-wise, now. I think we've dealt with all official business and can close?
  146. Tobias we're at AOB
  147. Kev AOB was the last item, yes.
  148. Kev It's not clear that we're actually still in it :)
  149. m&m so, if you're going to run, get your page up!
  150. Kev m&m: Done.
  151. Kev Although I should update it to not be a copy of the last eight years :)
  152. m&m jots a note to pester Lance about putting up an actual page
  153. Kev OK, I think we're done with AOB and are just chatting here?
  154. m&m Kev: you could go the bot route (-:
  155. m&m /nod
  156. Kev So, last call for AOB :)
  157. MattJ m&m, I heard you may not be in Portland... say it ain't so
  158. m&m I will not be in Portland )-:
  159. m&m not physically
  160. ralphm I'd like to chat a bit about Porland, outside this meeting
  161. m&m if there's a remote option, I'll join that
  162. Kev OK, let's close up then.
  163. Kev Thanks all!
  164. Kev bangs the gavel.
  165. ralphm Thanks!
  166. ralphm So, Summit #14
  167. Tobias thanks
  168. ralphm There's been some talk, the number of people signing up is rather low.
  169. ralphm Still, I do think it is worth it to meet up.
  170. Kev Yeah, I'm afraid we don't really have the cycles to lose anyone for a week at the moment, else I'd be inclined to attend.
  171. ralphm Not all talk with a large group like usual, but at least partially do some actual work.
  172. Zash m&m: Didn't someone mention that 280 + MUC was an issue? And using hints instead of the 280-only <private> would be nice.
  173. m&m Zash: I'm a moron … I see 280 and thought 288
  174. m&m I need to go back over 280
  175. m&m MUC private messages can be an issue
  176. Zash For MAM too
  177. m&m Why is the server applying carbons to things that don't come immediately from an active endpoint?
  178. ralphm (Summit) For example, our web site needs love, spec pages, splitting up XEP-0060. Maybe something like tutorials for publish-subscribe and other topics.
  179. Kev ralphm: On the pubsub topic, did you see Remko's blog post? I thought that was pretty neat.
  180. Kev Oh, damn, there was something I wanted to discuss in AOB. Nevermind, can do it out of band.
  181. stpeter is deep in explanations of XMPP and is not paying attention here
  182. m&m (-:
  183. ralphm Kev: yeah, stuff like that is great.
  184. Kev stpeter: Feel free to report back once you know about it :D
  185. ralphm Kev: I was looking at http://www.rabbitmq.com/getstarted.html
  186. Kanchil ralphm: http://www.rabbitmq.com/getstarted.html: RabbitMQ - Getting started with RabbitMQ
  187. ralphm Kev: and also, I am sensing that we should have an offering for people using XMPP as part of their application, without starting out with a full-fledged XMPP server.
  188. Zash m&m: Hm? A PM from a remote MUC looks exactly like a chat message from a s2s connection.
  189. ralphm Kev: of course the existing software to support this use case is lacking, so maybe we should try come up with what's needed for something like that
  190. Kev ralphm: Hmm. I'm not sure what the value of only having part of a server is. Or did I misunderstand?
  191. ralphm Kev: use case is something like Facebook. They started out with ejabberd, needed to replace most of the guts of the thing (like the session manager) and finally started rebuilding it from scratch.
  192. ralphm Kev: I did this for just publish-subscribe at Mediamatic
  193. m&m goes back to his day job
  194. ralphm Kev: and I am sure that many people trying to use XMPP as part of their application get stuck on this
  195. m&m Zash: I'm not understanding your terseness then
  196. m&m really does go back to his day job now
  197. Kev Facebook is a somewhat special case, because they were mapping an existing IM implementation onto XMPP at the boundary, most people don't have large internal IM systems. So the Mediamatic case is probably more interesting.
  198. Kev So, in what way was what you did there different to e.g. running up M-Link* and only using the pubsub bits.
  199. Kev [* Replace with server of choice]
  200. stpeter heh, the topic of XMPP compliance testing has arisen on this conference call :-)
  201. ralphm Kev: actually, I have exposed a model of a publish-subscribe node as an internal API, not unlike what web frameworks do for building web sites
  202. ralphm Kev: and then used that to glue it on top of the (HTTP API) of the website
  203. Kev I don't think this is the ideal medium for discussing this, sadly. What you describe sounds naively like putting a relevant API over the top of XMPP, rather than needing to cut bits out of servers.
  204. ralphm Kev: it also uses the s2s implementation in Wokkel, but you could also run it as a server-side component and have a (bare) server do that part.
  205. ralphm Kev: that might be true.
  206. tato has joined
  207. Kev I guess one option would be to register xmppformiddleware.com, and do much like the RabbitMQ thing, with how to do basic stuff in different languages. I would suggest that doing this through the XSF would result in too much need for fairness. e.g. if I was working on it, I'd pick Swiften for C++, and ignore Gloox, Stroke for Java and ignore Smack, etc.
  208. Kev I think it would be very unhelpful to have 37 different 'how to do it in Python' examples, for each of the libraries.
  209. ralphm Kev: oh, it doesn't really need to be an XSF thing at all
  210. Kev But I think it'd be a really interesting project to do outside the XSF.
  211. ralphm Kev: but a nice topic for the Summit
  212. Kev And I'd be willing and/or keen to work on such things with people (but not alone).
  213. ralphm Kev: also, make sure that you block out Summit #15 (Brussels) in your agenda. :-D
  214. Kev Point.
  215. ralphm (and those of your minions)
  216. Kev Haha. I have no minions, sadly. We're all Kurt's minions.
  217. ralphm Kev: all Kurt's minions then. Whatever makes you guys show up.
  218. Kev Do we have days for the summit yet?
  219. ralphm Kev: not yet
  220. Kev OK.
  221. Peter Waher has left
  222. ralphm I do know there is http://cfgmgmtcamp.eu on Monday and Tuesday. Not sure if that's a problem.
  223. Kanchil ralphm: http://cfgmgmtcamp.eu: Config Management Camp 2014, Gent
  224. m&m I thought the rough consensus was to do the summit before, not after?
  225. m&m because people are worn out after FOSDEM (-:
  226. ralphm yeah
  227. ralphm 30/31 seems fine to me
  228. Kev m&m: And because they can head home on the Sunday of FOSDEM, cutting a day off the trip :)
  229. ralphm Kev: well yeah, *those* people
  230. Kev I see the Sunday of FOSDEM as being by far the least productive of the four days, personally.
  231. m&m You mean the LOSERS! (-:
  232. m&m and miss out on a prime opportunity for more beer
  233. stpeter yay, finished with my conf call
  234. Lance has joined
  235. Kev m&m: I'm aware my desire to be at home is much stronger than most people's (and my desire for beer much less strong), yes.
  236. ralphm Kev: it is what you make of it. I've done some productive stuff by grabbing one or two other people into a hacker room and then do some speccing, in previous years
  237. Kev I don't claim it can't be productive, but I find it all exhausting, and I'd rather concentrate my energy on the other days :)
  238. ralphm Kev: I say you need more training.
  239. Kev Possibly.
  240. Kev stpeter: The remaining item that I forgot to put into AOB is how we're going to move Reachability forwards.
  241. Kev Or upwards, or whatever direction the process goes in.
  242. stpeter yes
  243. Kev pokes Emil again.
  244. stpeter is the meeting still going here or is this post-meeting chat?
  245. Kev Post-meeting chat.
  246. m&m it's the after-meeting
  247. stpeter ok
  248. Kev Good grief, do you think we've been going for 50 minutes? :)
  249. stpeter I doubted it!
  250. Kev Who are the people who're building things with the XEP, and how do we get them to confirm/deny that it's doing its job?
  251. stpeter I think I'll ping all the folks who provided feedback on the CUSAX spec
  252. Kev Thanks.
  253. stpeter I might have a non-CUSAX use case, too
  254. stpeter pokes the developers he's been working with on the side
  255. Kev This feels like it should be part of a vcard spec, rather than independent, but I'm not going to be Mr. Unpopular and do anything because of that. The world is what it is.
  256. stpeter sometimes you have more dynamic information that would not go into your vCard
  257. stpeter e.g., you walk into a conference room and based on near-field communication or simple old reading you discover the 'tel:' or 'sip:' URI for a video endpoint
  258. Kev Marvellous, I feel better about it now, thanks.
  259. stpeter once you walk out of the room, you don't want to update your vCard
  260. Kev I hadn't quite clicked it was an as-you-walk thing, when it talked about moving buildings.
  261. Kev Yeah, that makes sense.
  262. stpeter but I am not sure that people are building this into products yet, although I wish they would!
  263. stpeter ideally that stuff would be automated
  264. stpeter so I walk into a conference room and my XMPP client can push my temporary contact location to you
  265. Kev All makes sense, ta.
  266. stpeter if I have a more stable contact address (e.g., my configured SIP URI) then yes, that makes sense to put in my vCard for sure
  267. stpeter if that's not clear then it needs to be
  268. Zash Multiple vCards or vCard items in their own PEP nodes?
  269. stpeter Zash: why would I want to have multiple vCards? sounds confusing...
  270. stpeter curses at his inbox
  271. Kev stpeter: I'd suggest putting (e.g. changing their addresses as they walk from one room to another) to the bit in section 2 about dynamicness.
  272. stpeter Kev: yes
  273. ralphm stpeter: Persona. E.g. I have multiple google plus accounts (personal and company)
  274. Zash stpeter: Simplified access control, namespace/spec reuse, separation based on TTL
  275. Kev Spell it out for stupid people like me :)
  276. ralphm Zash: you arguably don't need multiple items for restricted access
  277. ralphm (you can serve up different content)
  278. Zash ralphm: Do we have anything for only sharing parts of vCards based on who's receiving it?
  279. Zash The OneSocialWeb people were working on something to address that, but I don't think it ever got submitted
  280. stpeter ralphm: BTW the folks I was chatting with earlier are going to use pubsub for most of their use cases
  281. ralphm Zash: you don't need additional protocol for the subscribing/retrieval part
  282. ralphm stpeter: cool
  283. Zash ralphm, but things like not giving out my private phone numbers to people not in my contact list or limiting it to a specific roster group
  284. ralphm Zash: you could do this as part of the implementation. Depending who asks, subscribes, you give a different view on the same data.
  285. Kev ralphm: We have no way of defining that though, I think.
  286. ralphm Zash: you might want to specify how to make a service do that.
  287. Kev So you could patch your server to do these things, but it's specific to your deployment.
  288. ralphm Zash: like with node configs
  289. Zash ralphm: Yeah
  290. ralphm my point was that you don't need additional protocol, per se
  291. ralphm My steak is calling. Back in a bit.
  292. Kev Mmmm. Steak.
  293. stpeter heh
  294. stpeter at some point I'll need to scroll up and see what all the discussion was about, but first I'm trying to finalize some summit details
  295. Tobias has joined
  296. stpeter hmm, last year we spent quite a bit on room / catering at the Summit, I'm sure I can get that down a bit this time
  297. Tobias at both meetings?
  298. stpeter no, just in Portland
  299. Tobias ahh..k
  300. stpeter the meeting rooms are free for me at the Cisco office in Diegem ;-)
  301. Tobias stpeter, maybe cisco also runs a catering business which needs to produce profits :D
  302. stpeter heh
  303. stpeter pizza boxes? ;-)
  304. Kev Mmmmm, pizza.
  305. Lance has left
  306. Lance has joined
  307. Lance has left
  308. tato has left
  309. tato has joined
  310. tato has left
  311. jabberjocke has joined
  312. Zash has joined
  313. Lance has joined
  314. Lance has left
  315. Lance has joined
  316. Zash has left
  317. Tobias has left
  318. tato has joined
  319. stpeter has left
  320. m&m has left